Annotation

Управленческий учет – это «обратная связь» с желаниями бизнесмена, которая показывает, достигнут результат или нет. Вы держите в руках руководство по «сборке», «настройке» и использованию управленческого учета. В книге пошагово описаны все этапы внедрения учета в компании, его корректировки под особенности вашего предприятия, даются советы по эффективному применению. Даны проектные документы, за которые консультанты нередко берут огромные деньги. В издании отражен уникальный опыт специалистов, много лет внедрявших управленческий учет в сотнях российских компаний. Приводятся комментарии руководителей и топ-менеджеров ведущих предприятий России: «Автомир», «Миэль», «Аптека 36,6» и других.

Рекомендуется руководителям и топ-менеджерам предприятий.

- Дмитрий Геннадьевич Слиньков

- 1. Введение

- 1.1. Наши эксперты

- 1.2. Структура Руководства пользователя

- 1.3. Что такое управленческий учет?

- 1.4. Анализ разных подходов к внедрению УУ

- 2. Управленческое планирование

- 2.1. Стратегическое управление

- 2.2. Как связать стратегию с бюджетом

- 2.3. Бюджетное управление

- 2.4. Сценарное планирование

- 2.5. Проектное и инвестиционное планирование

- 2.6. Консолидация финансовой информации

- 2.7. Контроль и анализ

- Трендовый анализ

- Сопоставление данных разных версий

- Сопоставление данных по разным объектам

- Анализ «что будет, если…»

- Анализ показателей эффективности

- 2.8. Финансовая модель данных

- 2.9. Подводные камни бюджетирования

- Бюджет по бухгалтерским принципам

- Бюджет заявок

- Бюджет виртуального кошелька

- Как избегать таких ошибок?

- 2.10. Управленческое планирование на примере фабрики валенок

- Стратегическое управление

- Сценарное планирование

- Бюджетное управление

- Контроль и анализ

- Два вида бюджета – годовой и оперативный

- Скользящее бюджетирование

- 3. Постановка УУ

- 3.1. Разработка политики УУ

- 3.2. Постановка планирования

- Стратегические сессии

- Постановка бюджетного управления

- 3.3. Постановка оперативного учета

- Проектирование бизнес-функций

- Проектирование бизнес-процессов

- Проектирование рабочих мест и должностных инструкций

- Процедуры масштабирования

- Центр компетенции и методологии

- Центр обработки данных

- Дополнительные сведения к постановке оперативного учета

- 4. Технологическая поддержка управленческого учета

- 4.1. Введение в комплексные системы класса ERP

- Разработка справочников. Несколько советов

- Заведение новой товарной единицы

- Основные справочники

- Ввод данных

- Одна или несколько

- Отчет

- Ликбез по многомерным базам данных

- 4.2. Классификация систем обеспечения УУ

- 4.3. Подходы к выбору программного приложения

- Разрабатывать или внедрять готовое

- Большая или маленькая

- «Тяжелая» или «легкая»

- Комплексная или сервисы

- Контрольный пример

- Запасной план

- 4.4. Выбор поставщика услуг по внедрению приложения

- Большой, но дорогой

- Конфиденциальность

- Интерес консультанта

- Пилотные проекты

- Референтный визит

- Команда

- 4.5. Как подготовиться к внедрению системы управленческого учета

- Проверка боем

- СМК

- Администратор

- Мотивационная программа

- 4.6. Методология внедрения

- Подход к созданию АСУП. Описание методики

- Классификация функций АСУП

- Стадии ЖЦ АСУП

- Особые замечания и советы

- Зависимость необходимости в автоматизации от зрелости компании

- 4.7. Устав проекта

- Управление проектом

- Порядок проведения собраний проектной команды

- Порядок ведения проектной документации

- Процедуры согласования

- Контроль и отчетность по исполнению планов

- 4.8. Как правильно вести проект внедрения системы УУ, или Подводные камни внедрения

- Работа над ошибками

- Ранжирование проблем

- Нагрузочное тестирование

- Разделение сред разработки и эксплуатации

- Проблемы отношений с исполнителем

- ТЗ – как договор

- ИТ-проект среди других бизнес-проектов

- Проектные риски

- Ошибки консультанта vs ошибки разработчика

- Забавный случай

- 4.9. Особенности автоматизации стратегического управления

- Все тот же Balanced Scorecard

- «Деревья надо знать по именам»[22]

- И другие официальные features

- Почем и как у других?

- 4.10. Современные тенденции развития ПО для бизнеса

- Основные понятия

- Проприетарное vs свободное ПО

- «ПО как услуга»

- Примеры «ПО как услуга» – Adaptive Planning

- Пример «свободного ПО» – Palo Server

- Основные поставщики ПО «по запросу»

- 5. Развитие УУ

- 5.1. Как рассчитать совокупную стоимость владения системой УУ

- Затраты на проект. Их тьма

- Возврат инвестиций

- 5.2. Теория жизненного цикла систем

- 5.3. МСФО и управленческий учет

- Связь управленческого учета и МСФО

- Практические пути получения международной отчетности

- Альтернативные мнения

- Примеры перекладки отчетности

- 5.4. Роль финансового директора во внедрении и развитии УУ, или «Последние дни» CFO

- 5.5. Что бы мы сделали по-другому

- Приложения

- 1. Руководство по целеполаганию

- Область применения

- Определения

- Назначение целеполагания

- Принципы целеполагания

- Общие рекомендации по целеполаганию

- Формат определения целей

- Связь целей компании, процессов и проектов

- Использование целей в проектах

- 2. Положение о финансовой структуре

- Структура центров финансовой ответственности

- Полномочия и ответственность

- Целевые показатели и показатели эффективности

- 3. Программа и методика испытаний

- 4. Устав проекта

- Общие сведения

- Границы проекта

- Финансовая консолидация

- Средства реализации

- Географические рамки

- Проектные риски

- Временные рамки проекта

- Организационная структура проекта

- Управление проектом

- Выполнение работ по проекту

- Задачи и функции участников координационного комитета и рабочей группы

- Порядок проведения собраний проектной команды

- Порядок ведения проектной документации

- 5. Пример тендерного задания

- Введение

- Объем работ

- Этапы и сроки проекта

- Требования к консультанту

- Договорные и юридические требования

- Контакты

- Библиография

- Нормативные ссылки

- notes

- 1

- 2

- 3

- 4

- 5

- 6

- 7

- 8

- 9

- 10

- 11

- 12

- 13

- 14

- 15

- 16

- 17

- 18

- 19

- 20

- 21

- 22

- 23

- 24

- 25

- 26

- 27

- 28

- 29

- 30

- 31

- 32

- 33

Дмитрий Геннадьевич Слиньков

Управленческий учет: постановка и применение

1. Введение

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

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

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

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

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

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

сомнения – правильный ли бизнес, хороши ли результаты, – управленческого учета нет», – Евгений Плаксенков, генеральный директор компании «Миэль».

Основная мысль книги проста – внедрять управленческий учет никогда не поздно и никогда не рано. Также верно и следующее утверждение: управленческий учет в том или ином виде есть всегда и везде. Потому что существует сам бизнес.

Фактически вы держите в руках бизнес-кейс довольно крупной гипотетической фирмы. Какие именно материалы необходимы сейчас, а какие пригодятся в будущем, решать вам.

1.1. Наши эксперты

ДМИТРИЙ НОВОСЕЛОВ, ФИНАНСОВЫЙ ДИРЕКТОР ОАО «ВАЛЕНТА)

ОАО «ВАЛЕНТА»

Компания была основана в 1997 году как ОАО «Отечественные лекарства». Сегодня она состоит из трех ОАО – «Валента Фармацевтика», «Новосибхимфарм» и «Красфарма».

«Валента» обеспечивает 15 % российского производства лекарственных средств, выпуская 200 наименований препаратов в большинстве социально значимых фармакотерапевтических групп. На стадии разработки и регистрации находится свыше 150 новых лекарств. Самые известные бренды компании – Фенотропил, Зорекс, Граммидин, Фенaзепам, Аминазин. Объем продаж в 2007 году составил 232 млн долларов США.

МИХАИЛ БУЛУШЕВ, ФИНАНСОВЫЙ ДИРЕКТОР СЕТИ МАГАЗИНОВ «СНЕЖНАЯ КОРОЛЕВА», В ПРОШЛОМ – ФИНАНСОВЫЙ ДИРЕКТОР КОМПАНИИ «АВТОМИР»

«АВТОМИР»

Группа компаний «Автомир» является крупнейшим автомобильным дилером России; представляет на рынке марки Лада, ГАЗ, Skoda, Renault, Nissan, Suzuki, Kia, Hyundai, Daewoo и Citroen. Среди ее корпоративных клиентов – более тысячи организаций, в том числе Coca-Cola, DHL, Nestle, Сбербанк РФ, Центробанк РФ, Danon, Siemens, TNT, Sony, Panasonic, Ehrmann и др.

«Автомир» – это 9 автосалонов, 14 сервисных центров и более 3000 человек персонала. Группа предоставляет полный спектр дополнительных услуг по автострахованию, покупке автомобиля в кредит, совершению сделок по схеме trade-in, гарантийному и сервисному обслуживанию, установке дополнительного оборудования и т. д.

ОЛЕГ УРНЕВ, ГЕНЕРАЛЬНЫЙ ДИРЕКТОР «ИЖОРСКОГО ТРУБНОГО ЗАВОДА» (ГРУППА «СЕВЕРСТАЛЬ»)

ЗАО «ИЖОРСКИЙ ТРУБНЫЙ ЗАВОД» (ИТЗ)

Предприятие по производству труб большого диаметра, входит в структуру ОАО «Северсталь» – головного предприятия металлургического дивизиона холдинга «Северсталь-групп».

Годовой объем производства – 600 000 т одношовных сварных труб. Характеристики продукции ИТЗ уникальны для трубной отрасли России.

Численность работников составляет 1000 человек.

БОРИС РЯБОВ, ДИРЕКТОР ПО ИНВЕСТИЦИЯМ КОМПАНИИ «РУКОМ», В ПРОШЛОМ – ДИРЕКТОР ПО РАЗВИТИЮ БИЗНЕСА АПТЕЧНОЙ СЕТИ «36,6»

ЗАО «АПТЕКИ 36,6»

В настоящее время аптечная сеть «36,6» насчитывает 1224 аптеки в 29 регионах России (данные по состоянию на 01.01.2008). Является соучредителем и членом некоммерческой профессиональной организации Российская Ассоциация Аптечных Сетей (РААС).

В компании работают более 12 000 сотрудников.

Консолидированная выручка за 2006 год составила 528,9 млн долларов США, EBITDA – 25,5 млн долларов США, чистая прибыль – 34,5 млн долларов США.

ЕВГЕНИЙ ПЛАКСЕНКОВ, ГЕНЕРАЛЬНЫЙ ДИРЕКТОР КОМПАНИИ «МИЭЛЬ»

«МИЭЛЬ»

Инвестиционно-девелоперский холдинг «МИЭЛЬ» был основан как компания «МИЭЛЬ-Недвижимость» в октябре 1990 года. Основными направлениями деятельности сегодня являются инвестиции, девелопмент, консалтинг, брокерские услуги и управление активами. Сеть холдинга насчитывает 38 отделений, пять из которых расположены в городах Подмосковья, семь – на территории других регионов. Общий портфель проектов превышает 3 млрд долларов США. При этом 1,5–2 млрд – сегмент загородного строительства, остальное – жилье бизнес-класса в Москве и регионах.

По итогам 2006 года ЗАО «МИЭЛЬ-Недвижимость» (одна из компаний холдинга) вошла в число крупнейших компаний России (238 позиция по данным РА «Эксперт») и заняла 131 место среди крупнейших частных фирм по версии журнала Forbes. «МИЭЛЬ» трижды удостаивалась титула «Супербренд», присуждаемого независимым Экспертным Советом самой известной, обладающей лучшей репутацией и показывающей исключительную деловую активность компании.

Рейтинговое агентство «Эксперт» включило «МИЭЛЬ» в список 400 крупнейших компаний России по объему реализации в 2005 году.

1.2. Структура Руководства пользователя

1. Введение

Что такое «Управленческий учет»? Приводятся высказывания и размышления экспертов (руководителей крупных преуспевающих фирм, внедривших у себя управленческий учет). Даны определения понятий «планирование», «оперативный учет» и многих других ключевых терминов. Анализируются разные подходы к планированию и учету.

2. Управленческое планирование

Планирование столь важно для бизнеса, что прежде чем перейти к вопросам постановки управленческого учета (УУ), сначала мы решили провести «ликбез»: наглядные примеры раскрывают суть стратегического и бюджетного планирования, контроля и анализа. Лишь в данной главе книга напоминает учебник. Но здесь это необходимо, чтобы разобраться в терминологии.

3. Постановка УУ

Основа основ – политика управленческого учета. Описывается назначение и приводится структура этого документа. Затем идут два больших раздела:

Постановка планирования

Постановка оперативного учета

В них описаны основные документы, составление которых необходимо для постановки УУ. Разобраны этапы проектирования основных элементов управленческого учета. Примеры документов есть в приложениях, а сами этапы дополнены примерами из практики и мнениями экспертов.

4. Технологическая поддержка УУ

Автоматизация – венец внедрения управленческого учета. Поэтому сначала мы рассказываем, с помощью каких инструментов решаются те или иные задачи УУ: Как выбрать поставщика информационной системы (ИС)? Какие подходы к внедрению ИС существуют? Как выбрать консультанта? Затем подробно описываем процесс внедрения, перемежая текст мнениями экспертов.

5. Развитие УУ

В этой части мы размышляем о путях дальнейшего развития управленческого учета на российских предприятиях. Читатель познакомится с теорией жизненного цикла информационных систем. Узнает, что связывает УУ и МСФО. Эксперты расскажут об эволюции роли современных финансовых директоров.

Приложения на CD

На диске собраны все упомянутые в Руководстве рабочие материалы в электронном виде. В частности: Устав проекта, Предварительная финансовая модель (Excel), Инструкции пользователя, Регламенты, Бизнес-процессы, Положения и многое другое. Кроме того, диск содержит уникальный в своем роде материал – Презентацию «Управленческий учет. Руководство пользователя» в формате PowerPoint. Там же приводятся некоторые бесплатные программные продукты, позволяющие значительно упростить постановку и внедрение УУ.

1.3. Что такое управленческий учет?

Если прямо сейчас вам потребовались цифры для:

• составления плана развития бизнеса на следующий год;

• анализа результативности того или иного вида деятельности;

• оперативного «перепланирования» для изменения цен реализации; принятия решений любой степени важности…

…и при этом вы не имеете таких цифр на руках, значит, вам нужен управленческий учет.

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

Управленческий учет – резко ожидаемый РЕЗУЛЬТАТ. Достоверный план, подкрепленный красноречивыми цифрами. Подробнейший, понятный (и желательно – интерактивный) отчет о деятельности вашей фирмы. Разумно агрегированные (но обладающие возможностью «сверления») данные о затратах в текущем периоде. Любая актуальная на сегодняшний день информация, необходимая лично вам для того, чтобы оценить ситуацию и принять правильное решение.

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

• стратегическое управление;

• управление эффективностью;

• управление рисками.

Соответственно целями УУ в этих областях являются:

1) формулирование стратегии;

2) планирование и организация бизнес-деятельности;

3) помощь в принятии решений;

4) оптимизация использования ресурсов;

5) поддержка генерации финансовой отчетности;

6) сохранение активов.

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

• анализ отклонений;

• анализ финансовых показателей;

• разработка систем оценки бизнеса;

• ценообразование;

• анализ рентабельности продукции;

• составление отчетности по географическим сегментам, направлениям бизнеса и сегментам рынка;

• разработка показателей управления сбытом;

• анализ затрат;

• анализ затрат и результатов;

• анализ прибыльности клиентов;

• принятие решений о капиталовложениях;

• анализ «покупать или брать в аренду»;

• стратегическое планирование;

• консультирование в области стратегического управления;

• представление и обмен внутренней финансовой информацией;

• прогнозирование объема продаж и финансовое прогнозирование;

• составление краткосрочных бюджетов;

• распределение затрат;

• распределение ресурсов и оценка эффективности использования.

Люди, обладающие такими навыками, обязаны подтвердить уровень своей подготовки сертификатами CMA (Certified Management Accountant), выданными, например, CIMA или IMA. Однако здесь есть несколько важных «но»:

• во-первых, зарплата персонала, который обладает названными сертификатами, чрезвычайно высока;

• во-вторых, найти таких специалистов в приемлемые сроки тяжело и затратно;

• в-третьих, наличие сертификата не означает стопроцентную применимость знаний конкретного специалиста в вашем уникальном бизнесе.

Как быть? Вспомните, желая разобраться в новом вопросе, вы:

1) собираете максимум информации по интересующей теме и систематизируете ее;

2) знакомитесь с людьми, которые разбираются в данном вопросе, и поддерживаете с ними контакт.

Будем считать, что первое уже сделано – вы держите в руках книгу «Управленческий учет: постановка и применение». «Это реальные знания плюс опыт лидеров преуспевающих компаний, которые внедрили и используют управленческий учет», – Е. Плаксенков.

Второй шаг тоже можно сделать самому – достаточно прочитать книгу. Ведь здесь собраны примеры из бизнес-практики.

Поскольку тема УУ многообразна и «заполемизирована» в научной литературе, мы решили знакомить вас с порой противоречащими друг другу (или пресловутой теории) формулами – от лица наших экспертов. Ценность каждой формулы в том, что она реально работает. А выбор остается за вами.

На самом деле все возможные цели управленческого учета давно описаны в документах Американского Института Управленческого Учета (IMA) и английского Chartered Institute of Management Accountants (CIMA). Многие проблемы УУ приводятся в соответствующих стандартах (Statements on Management Accounting), которые разрабатываются с конца 1970-х годов. Методик сегодня предостаточно, и о них много пишут. Но…

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

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

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

Б. Рябов: «Аптечная сеть возникла в 1998 году; до 2002–2003 года торговых точек было немного. Когда структура стала усложняться, уже были сформулированы требования к существованию в новых условиях: необходимость управленческого учета и подготовки отчетности одновременно по отечественным стандартам и МСФО. Однако из-за этих самых требований каждый раз, когда фирма совершала очередное приобретение, приходилось перезапускать управленческую отчетность нового члена команды. Конечно, задачу решали, но сколько головной боли: разные учетные системы, неодинаковое качество информации и т. п. Да, речь идет о торговле, но везде есть свои особенности. Например, у вновь купленной компании может быть особая схема товародвижения с логистикой».

В зависимости от ситуации вы сразу переходите к той или иной части УУ, чтобы ее усовершенствовать. В укрупненном виде такими частями являются:

• Планирование.

• Оперативное управление.

• Автоматизация управления.

К любой из названных частей можно возвращаться снова и снова, шлифуя систему УУ.

1.4. Анализ разных подходов к внедрению УУ

Что первично: «план» или «учет» – ответ далеко не однозначный.

Для многих из нас ответ очевиден – первично планирование. Тогда почему каждый второй человек на планете не любит планировать? Потому что планы строятся на неопределенности. Мы ее боимся и прикрываем свой страх словами: «Как я могу спрогнозировать объем продаж совершенно нового продукта да еще с разбивкой потипам клиентов?». Никто и никогда не планирует чистить зубы по утрам. Вы просто встаете и чистите – это очевидное, повторяющееся, предсказуемое и необходимое для здоровья действие. В планировании нуждаются слабо предсказуемые события. Шахматисты говорят: лучше плохой план, чем никакого.

Разберем несколько примеров.

Компания – дистрибьютор электротоваров; клиенты – розничные магазины. Данный бизнес вполне поддается планированию, так как:

1) планы реализации можно собирать с клиентов;

2) планы поставок можно составлять вместе с поставщиками;

3) нет производственного звена, а следовательно, и непредсказуемости.

Упаковочно-полиграфическое производство. Такой бизнес менее подвержен планированию, так как:

1) существует определенная доля разовых клиентов;

2) время от времени возникает необходимость оперативного перепланирования загрузки мощностей;

3) необходимо иметь два вида плана выработки: долгосрочный в квадратных метрах (+ обрез) и краткосрочный в штуках конкретных изделий и заказов.

В случае с розничным магазином планирование возможно, но при хорошем категорийном менеджменте.

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

1. Рамки проекта не являются жесткими по всем основным параметрам: цель проекта, срок, бюджет, этапность, состав исполнителей. Все меняется в ходе проекта.

2. Проект обрастает «допродажами» – дополнительными услугами, так называемыми «расширениями проекта».

3. При хорошо поставленном консалтинговом бизнесе проект долго приносит дополнительный заработок (абонентские платежи, оплата в рассрочку, лицензионные отчисления, роялти и т. п.).

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

Строительная деятельность. На первый взгляд вполне предсказуемый бизнес – при условии обеспеченности заказами на планируемый период[1]. Но если заказов в достаточном объеме нет, планируются условные величины (сданные в эксплуатацию или проданные квадратные метры). Главным источником неопределенности для строителей является планирование затрат. Поэтому им лучше начать с постановки учета, чтобы, как минимум, составить работоспособный классификатор затрат и уже после перейти к планированию.

«Так с чего же начать?»…

Посмотрите на таблицу «Сколько вам нужно планов» (табл. 1.1). Здесь в разбивке по приведенным выше примерам бизнесов приведены основные планы: Сбыта/Производственный/Закупок.

Таблица 1.1. Сколько вам нужно планов

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

Два ключевых узких места планирования:

1) производство;

2) поставки, особенно – многозвенные.

Превышение периодов поставки над периодом прогнозирования – другая головная боль плановиков. Как ни странно, со спросом все проще: прогноз возможен даже на основе «чутья» коммерсанта.

Дальше – производство. Существует неплохая классификация методов производственного планирования по принципу ТПЗК – точка привязки заказа клиента (рис. 1.1).

Рис. 1.1. Точка привязки заказа клиента

Каждый из этих типов предъявляет те или иные требования к алгоритмам производственного планирования.

Если вы все-таки решили начать исключительно с оперативного учета, это ваше решение. НО помните:

• Начиная с учета, вы всегда смотрите назад.

• Начиная с учета, вы откладываете шанс научить своих сотрудников планировать и отвечать за свои планы.

Всегда возможна ситуация, при которой вы даете старт проекту нормализации учета в отделе закупок и производства, а ежегодное и оперативное планирование запускаете в отделе реализации… Прочтите хотя бы несколько глав этой книги и поймите, подходят ли вам методы «лоскутных инноваций».

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

Мы попытаемся исправить это упущение. Раз уж все привыкли к УУ, мы оставим название данной дисциплины, но разобьем ее на две части:

1) планирование;

2) оперативный учет (ОУ).

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

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

2. Управленческое планирование

Для современного специалиста по управленческому учету понятия «планирование» и «анализ» неразрывны: планируя, мы анализируем разные сценарии; анализируя, планируем, исходя из принципа «Что будет, если…».

Контрольные функции также являются неотъемлемой частью планирования (контроль исполнения планов и своевременное «перепланирование») и анализа (анализ отклонений, поиск причин и т. п.). Таким образом, планирование, контроль и анализ – комплекс взаимосвязанных управленческих процессов, которые называются управлением эффективностью предприятия (BPM – Business Performance Management). Международные аналитики, в частности Gartner Group, так его определяют: «зонтичный термин, описывающий методологии, показатели, процессы и системы, используемые для контроля и управления результативностью деятельности предприятия».[2]Между тем, за последние два года термин «управление эффективностью» стал ведущим в сфере BPM.

Профессиональные сообщества часто связывают его с ключевыми показателями деятельности (KPI).

Итак, что нужно знать, чтобы овладеть управленческим планированием?

1) стратегическое управление, целеполагание, ключевые показатели эффективности;

2) взаимодействие стратегии с бюджетом;

3) бюджетное планирование, проектное планирование, сценарное планирование;

4) консолидация финансовой информации;

5) контроль и анализ, методики анализа.

Именно в таком порядке мы расположили материал данного раздела.

Некоторое время назад, давая интервью, автор этой книги в доступно-шутливой форме осветил все вышеперечисленные аспекты управленческого планирования. Практическое пособие a la «Управленческое планирование для чайников» вы найдете в конце главы.

Также вы найдете здесь описание типичных ошибок современных бюджетных процессов.

2.1. Стратегическое управление

Иногда самое первое тактическое решение, которое вы воплощаете в жизнь, меняет все ваши стратегические планы.

Том Купер, руководитель административной службы Access Management

Формальное определение бизнес-стратегии: «направление и область деятельности организации в долгосрочной перспективе. позволяющие организации получить определенные преимущества путем перераспределения ресурсов в условиях меняющейся внешней среды с целью удовлетворения требований рынка и ожиданий групп влияния»[3].

Стратегия есть у любого бизнеса. Если вы – собственник, для вас стратегия – это слово. Слово, данное партнерам, акционерам, инвесторам, самому себе. Утверждать, что ваша компания станет первой на рынке через три года – полдела. В это должны поверить сотни (или даже тысячи) людей, которые идут за вами. Как довести свою стратегию до каждого, чтобы все, как единый механизм, работали над ее реализацией? Здесь необходимо стратегическое управление.

Основные задачи стратегического управления:

• Определение целей компании с учетом рыночной ситуации.

• Определение средств достижения этих целей.

• Сегментация, то есть разделение общей цели на подцели.

• Разработка соответствующих перспективных планов и программ.

• Оценка эффективности деятельности компании.

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

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

• ствол – основная цель компании;

• стволовые ответвления – стратегические инициативы;

• ветви – тактические шаги, проекты и планы;

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

Если исходить из формального, сущностного описания стратегического плана, перечень основных типов объектов стратегического планирования выглядит следующим образом:

• Миссия – смысл существования компании.

• Цели – общие определения целевого направления деятельности компании.

• Задачи – действия, направленные на достижение целей на определенный период.

• Стратегические инициативы – определение путей и методов достижения целей.

• Тактики – особые действия по выполнению различных стратегий.

• Допущения – основные предположения, допущения и условия достижения поставленных задач.

• Риски – потенциальные риски, влияющие на процесс выполнение стратегии.

• Ключевые показатели эффективности – показатели эффективности, позволяющие оценить достижения при выполнении задач с использованием той или иной тактики.

Для упрощения понятия «Задача» и «Стратегическая инициатива» можно объединить в один термин – «Задача». Я и мои клиенты так называем объекты, направленные на достижение стратегических целей. Но в исключительных случаях, когда компания начинает новые виды деятельности, выпуск оригинальных продуктов, делает приобретения и т. п., – все «прорывные» действия, необходимые для достижения новых амбициозных и необычных целей, правильнее именовать «Стратегической инициативой». Тем самым вы значительно повысите внимание к ним.

Пример объектов.

Современный производитель электроники для потребительского рынка мог бы так сформулировать свой стратегический план[4]:

Миссия: Стать мировым лидером в области производства электроники для потребительского рынка.

Цель: Расширить продуктовую линию сотовых телефонных аппаратов.

Задачи и оценки: В следующем году довести долю общей выручки, полученной от продаж сотовых телефонов, до 35 %. Увеличить общую выручку на 5 %.

СИ 1: Захватить новый рыночный сегмент – люди старшего возраста.

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

КПЭ 1а. Произвести 1000 новых телефонных аппаратов к маю.

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

КПЭ 16. Подписать два партнерских соглашения к апрелю.

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

ПРИМЕР

Стратегия: «Эффективная рекламная кампания»

Тактика 1:

• Целевое значение: 400 газетных заметок в год или 100 заметок в квартал.

• Факт: 90 заметок за квартал 1;

• Эффективность: 90 %.

Тактика 2:

• Целевое значение: 24 важные статьи в год или шесть статей в квартал.

• Факт: три статьи за квартал 1.

• Эффективность: 50 %.

Чтобы измерить, насколько хорошо выполняется эта стратегия, вам надо оценить эффективность выполнения двух тактик по приведенной ниже схеме.

Таблица 2.1

Многим трудно решиться и проставить реальный вес достижения какого-либо неисчисляемого (качественного) показателя. Здесь можно посоветовать лишь одно: довериться интуиции и по окончании каждого отчетного периода пересматривать плановые значения весов. «Руководство по целеполаганию», полностью опубликованное в приложении к данному Руководству, поможет вам понять, как именно нужно ставить цели.

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

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

Многие исследования показывают, что на Западе более 90 % фирм с подробнейшими стратегическими планами на практике не добиваются поставленных целей.

В ходе опроса, проведенного Industry Week совместно с MPI в 2007 году, всего 26,9 % руководителей американских заводов объявили, что занимаются стратегическим планированием. 53 % из них приходятся на средние и крупные предприятия с количеством занятого персонала от 500 человек.

Источник: IW/MPI Census of U. S. Manufacturers – 2007.

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

1) действия/бездействие руководства;

2) бизнес-процессы реализации стратегии;

3) информационное обеспечение, поддерживающее стратегическое управление.

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

Я всегда предлагал своим клиентам «рецепт» первого шага, неплохо описанный теми же Нортоном и Капланом. А они, как известно, более 15 лет изучают деятельность компаний, добившихся серьезных успехов благодаря внедрению системы BSC. Этим компаниям удавалось сделать стратегию понятной для сотрудников и наладить механизм контроля за выполнением намеченного. Лучше других справлялись со стратегическим разрывом организации, в структуре которых было специальное подразделение, отслеживавшее все процессы, связанные со стратегией. Так называемые отделы управления стратегией (ОУС).

«Те, кто думает, что речь идет всего-навсего о новом названии для традиционного отдела стратегического планирования, ошибаются: в действительности ОУС выполняет совсем другие функции. Отделы планирования, как правило, составляют план реализации стратегии на ближайший год, но процессом реализации не занимаются. Между тем компании, использующие BSC, уделяют серьезное внимание пропаганде корпоративной стратегии, понимая, что без этого эффективное исполнение невозможно. Они следят за тем, чтобы общекорпоративный план нашел адекватное отражение в планах всех отделов и департаментов; чтобы реализуемые в компании мероприятия способствовали выполнению общего плана, а программы профессионального совершенствования и индивидуальные рабочие планы сотрудников были скоординированы со стратегическими целями. Более того, такие компании постоянно проверяют актуальность принятых стратегий и проводят их корректировку в соответствии с меняющимися условиями конкуренции. Для координирования всей этой деятельности и необходим ОУС. И хотя новая структурная единица берет на себя не всю работу по реализации стратегии, она становится центром управления; органом, который налаживает процессы в масштабах всей компании» (Роберт Каплан, Дэвид Нортон, «Отдел управления стратегией», HBR, январь, 2006).

Советую вам ознакомиться с данной статьей. Примечательно, что в ней есть практическая рекомендация по численному и функциональному составу отдела управления стратегией. Кроме того, опубликовано несколько кейсов – примеров удачного устранения стратегического разрыва с помощью ОУС (Роберт Каплан, Дэвид Нортон, «Отдел управления стратегией», HBR, январь, 2006).

МНЕНИЕ ЭКСПЕРТОВ

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

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

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

Степень важности стратегического планирования, конечно, зависит от размера бизнеса. Пожалуй, не стоит требовать четкой формализованной стратегии от владельца скромного магазинчика «у дома». Но даже ему нужна бизнес-идея: понимание, чего и каким образом он хочет достичь в принципе. И за счет чего сможет обойти конкурентов. Если мы поднимаемся на уровень выше (скажем, до небольшого производственного бизнеса), то здесь уже должна быть четкая бизнес-цель: компании необходимо понимать, какой она видит себя через три-пять лет. Бизнес-цель – далеко не полноценная бизнес-стратегия, но реальная точка опоры в нестабильном мире.

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

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

Никита Савьяк, заместитель генерального директора по экономике ОАО «КУЗОЦМ»[5]

Кейс № 3 (16) 2008 «План в японском стиле»

«Самое важное – думать о будущем. Каким бы оно ни было фантастическим, о нем надо думать. В режиме «мы хотим прийти в это состояние и давайте подумаем, какими мы должны стать». Данная нить размышлений помогает определить узкие места, на выявление которых у компании могут уходить годы, и предотвратить ситуации, когда вчера надо было начать что-то, без чего завтра будет невозможно существовать. Это очень важный момент. Его нельзя назвать стратегическим планированием – слово несколько затасканное. Просто надо взять за правило думать об этом раз в квартал. Во-первых, управленческий процесс выявляет неспособность некоторых быстрорастущих компаний мыслить в ракурсе «куда мы вообще хотим прийти». А если не знаешь, куда идти, точно придешь не туда. Во-вторых, показывает неспособность конструировать реальность. Это явление носит, скорее, технический характер: выстроить последовательность, что нам нужно для достижения цели. Если первая сложность зависит от предпринимателя, который не смог вырасти из действительности времен создания бизнеса, то вторая – от наличия или отсутствия навыков и опыта. Предприниматель не знает, что произойдет с бизнесом в период роста. У него еще нет соответствующего опыта. Важно признаться себе в этом, искать такой опыт, менять управленческую команду. Например, обновлять кадры. Потому что в определенный момент, когда фирме, скажем, понадобятся крупные деньги для развития, старые сотрудники пойдут за кредитом в Сбербанк, хотя, возможно, пора собирать консорциум и добывать средства другими методами. Важно научиться планировать статические картинки – как достичь цели (и инвестиционную составляющую, и процессную), и рассматривать бизнес с точки зрения достаточности персонала. Если делать это честно и аккуратно, станут понятны вещи, которые организация не знает. В частности, на что обращать внимание, если занимаешься поддержкой принятия решения».

Борис Рябов, «Сеть аптек 36,6»

2.2. Как связать стратегию с бюджетом

Что такое хороший стратегический план? Аналитики называют восемь основных признаков такого плана:

1. Отвечает на прямые ключевые вопросы: «Куда мы идем?», «Как мы собираемся туда попасть?» и «Что произойдет, если что-то пойдет не по плану?». Эффективные организации всегда составляют «План Б».

2. Должен освещать три группы действий организации:

1) действия по поддержанию текущих операций;

2) действия по улучшению текущих операций;

3) новые проекты или инициативы, которые готовятся к запуску.

3. Всегда сфокусирован. Эффективные компании никогда не планируют все до мелочей.

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

5. Объединяет стратегию с тактикой. Любое тактическое действие высокоэффективные организации связывают с причинно-следственными диаграммами, показанными на рис. 2.1.

Рис. 2.1. Хорошие планы устанавливают причинно-следственные связи

Понимая эти связи, сотрудники начинают идентифицировать реальные «драйверы успеха».

1. Измеряем. Цели и задачи всегда имеют ожидаемый измеримый результат.

2. Обязательно содержит имена ответственных за их исполнение лиц.

3. Учитывает конкретные предположения, допущения и условия, изменение которых влечет изменение самого плана.

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

Действия топ-менеджмента:

1. Определить ключевые стратегические цели.

2. Описать стратегические задачи и результаты (табл. 2.2).

Таблица 2.2. Стратегические задачи и результаты

3. Задокументировать предположения, допущения и условия достижения поставленных задач (табл. 2.3).

Таблица 2.3. Предположения, допущения и условия достижения поставленных задач

Действия операционных (линейных) руководителей:

1. Разработать тактические шаги и высокоуровневый операционный бюджет (табл. 2.4).

Действия менеджеров всех уровней:

1. Оценка и минимизация рисков.

2. Проверка плана на целостность и финализация стратегического плана.

Таблица 2.4. Тактические шаги и высокоуровневый операционный бюджет

2.3. Бюджетное управление

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

Лично мне нравится более емкое, но точное определение: «Бюджет – это краткосрочный план достижения стратегических целей».

Чем отличается планирование от бюджетирования? Бюджетирование – синоним делегирования. С определенного момента развития компании топ-менеджмент ощущает потребность в переносе части ответственности за результат своей работы на подчиненных. Как только они начинают делегировать финансовую ответственность, возникает бюджетирование. Каждое подразделение, наделенное делегированными правами, называется Центром Финансовой Ответственности (ЦФО). (Более подробно о ЦФО и финансовой структуре см. главу 3 «Постановка УУ», раздел 3.2 «Постановка планирования».)

Но прежде всего нужно сформулировать цели введения на вашем предприятии бюджетного управления (вы еще не прочитали приложение про целеполагание?). Мы уже доказали, что бюджет идет в связке со стратегией. Однако всегда есть конкретные причины, почему именно вам необходимо бюджетное управление. Давайте разберем пример.

Компания-ритейлер имеет централизованное управление и централизованную же операционную деятельность: закупки и учет осуществляются через центральный офис. Сеть

принадлежащих ей магазинов находится в Москве и Московской области. На данной фазе развития компания может иметь стратегию и при этом совершенно не нуждаться в бюджетном управлении. Но проходит время и у нее появляется еще несколько магазинов в одной из областей, расположенных за Уралом. Возникает экономическая необходимость открыть дочерний офис и делегировать ему часть управленческих функций. Это уже повод задуматься над введением бюджетного управления. Если руководитель фирмы – дальновидный менеджер и заранее планирует экспансию в регионы, он будет выращивать управленческие кадры, находясь еще в пределах московской области. И он придумает, как наделить этих потенциальных руководителей региональных офисов хотя бы минимальными полномочиями уже сейчас, чтобы они готовились самостоятельно возглавить ЦФО. Заодно компания постепенно начала бы привыкать к понятию «бюджетное управление».

В первом случае цель введения бюджетного управления привязана к общей стратегии «ветками»:

Стратегическая инициатива «Региональная экспансия» – Тактический шаг «Создание региональных офисов».

Стратегическая инициатива «Поддержание базовых операций» – Тактический шаг «Контроль и оптимизация затрат».

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

Традиционно основные показатели развития компании формирует совет директоров. Затем они спускаются ниже на функциональных директоров и заместителей.

Д. Новоселов: «Процесс бюджетирования – некий цикл. И бюджетирование, и планирование делятся на несколько этапов. Этап верхнего уровня или самый главный этап – составление стратегического плана компании. Даже, скорее, бизнес-плана. Это выражение в цифрах стратегии компании, например: «через пять лет мы достигнем таких-то размеров; для этого потребуются такие-то ресурсы». Из стратегического плана берем конкретный год и говорим, какие целевые показатели нужно достигнуть при составлении бюджета. Что является целевыми показателями? Это выручка, EBITDA, уровень «закредитованности», чистая прибыль.

Менеджмент компании определяет, какое количество ресурсов потребуется для достижения необходимых результатов по выручке. При этом расход ресурсов можно выразить в цифрах. Это и будет бюджет расходов. Сначала все подразделения делают заявки на расходы ресурсов, чтобы обеспечить выручку. Первый этап – объем выручки, затем – производства, далее постепенно формируются расходы остальных подразделений».

Вы, наверное, уже догадались, что планы должны меняться. Ведь собственное мнение не меняют только дураки и мертвецы (так говорили древние). Если серьезно, то в бюджетировании нормальной практикой является закрепление основного годового бюджета в качестве некоего мастер-бюджета. По окончании первого отчетного периода (квартала или месяца) он зачастую пересматривается. Недовыполненные показатели первого квартала повышают показатели второго и т. д. Поэтому, оставив мастер-бюджет в неприкосновенности, вы создаете операционную его версию. Она является рабочей для всех ЦФО. Однако входными данными для нее всегда остаются не только план-факт анализ завершенного периода, но и мастер-бюджет.

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

Иногда используется нескольких версий не только плана, но и факта; в ряде компаний их количество доходит до четырех. В принципе, если позволяет технология, можно использовать и несколько версий факта:

• полностью подтвержденные документами операции;

• с учетом условных операций;

• с учетом неклассифицированных операций.

Теперь несколько слов о годовом бюджете. Последнее время проработка бюджета все чаще не привязывается к определенной дате. Важные события, такие как появление нового конкурента, поглощение компании и т. п., должны инициировать составление нового бюджета независимо от того, когда они произошли.

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

Бюджет – это три классические формы финансового бюджета:

• Бюджет прибылей и убытков;

• Бюджет движения денежных средств;

• Балансовый бюджет.

Часто отдельной формой финансового бюджета является инвестиционный бюджет.

Чтобы получить финансовый бюджет (рис. 2.2), необходим бюджет операционный. Он состоит из следующих отчетных форм:

• бюджета продаж;

• бюджета производства;

бюджета производственных запасов; бюджета прямых затрат на материалы; бюджета производственных накладных расходов; бюджета прямых затрат на оплату труда; бюджета коммерческих расходов; бюджета управленческих расходов.

Рис. 2.2. Схема бюджетного планирования

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

Операционные бюджеты формируются путем суммирования «мини-Р&Ь» и «мини-БДДС» всех ЦФО. На большинстве предприятий ЦФО создают лишь бюджет прибылей и убытков, чаще – бюджет прибылей и убытков плюс упрощенный БДДС. То есть в бюджете показывается то, на что ЦФО может влиять.

Ответственность ЦФО имеет несколько уровней. Полное делегирование – большая редкость. Оно возможно только в обособленных проектах, под которые создается отдельное юридическое лицо. Когда материнская компания не собирается вмешиваться в операционную деятельность «дочки». Полное делегирование заключается в назначении исключительно стратегических показателей. Способ их достижения материнскую компанию до поры до времени не касается.

При неполном делегировании возникает, как минимум, два инструмента, сдерживающих затраты ЦФО:

1) контроль на одной из стадий возникновения затраты (см. врезку «Стадии возникновения затрат»);

2) контроль и сдерживание на стадии планирования платежей компании.

Жизненные стадии затраты:

– бюджет;

– набор заявок;

– утвержденная заявка;

– тендерный запрос;

– контракт;

– заказ;

– накладная или акт;

– платеж.

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

2.4. Сценарное планирование

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

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

2.5. Проектное и инвестиционное планирование

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

Петр I

За последнюю четверть века у ведущих компаний мира сложился определенный порядок инвестиционного планирования. Ежегодно представители топ-менеджмента встречаются и обсуждают стратегию роста. Как правило, разговор начинается с определения ниш, где налицо недостаток предложения. Затем речь заходит об оценке внутренних потребностей компании и о том, насколько квалификация персонала и ресурсы позволяют использовать существующие возможности. Если ресурсов недостаточно, может последовать предложение о поглощении или создании СП с другой компанией. Ну, и напоследок присутствующие обсуждают финансирование и определяются с приоритетами. В каждой компании этот процесс имеет свою специфику. Одни предпочитают двухлетний цикл планирования, другие – пятилетний. Кто-то собирался в узком руководящем кругу, другие приглашают сотни менеджеров. Есть любители заседать на Карибах, а иных вполне устраивает местный Hyatt. Но суть всех этих обсуждений одна – сначала выработать стратегию, а потом найти деньги на ее реализацию. Похоже, времена меняются. У большинства компаний нет недостатка в идеях, но идеи – не тот фактор, от которого все зависит. Теперь в дефиците капитал. Поэтому успешные компании сегодняшнего и завтрашнего дня сначала обсуждают источники финансирования и лишь затем переходят к стратегии.

Майкл Маккеон, Симус Макмэон Сеть для инвестиционного капитала. Как планировать развитие в условиях мирового финансового кризиса // Кейс. 2008. № 3 (16).

Проектное планирование равносильно инвестиционному, потому что любой инвестиционный проект подразумевает план.

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

Деятельность эффективного менеджера состоит из проектов. У проекта есть четкая цель, конкретный ожидаемый результат, ответственный менеджер; выделены ресурсы; определено время исполнения. Даже на предприятиях серийного производства. Ведь они тоже развиваются, а любое развитие – это проект. Значит, проект должен быть одним из измерений в модели бюджетного управления, которые закладываются в финансовую модель данных (см. «Финансовая модель данных»).

Проектное планирование осуществляет менеджер проекта. При этом проект рассматривается как отдельный ЦФО. Проекты связаны между собой, и их бюджетное управление влияет на бюджет компании в целом. Очень важно отслеживать денежные потоки, причем именно по проектам, а не по контрактам (в рамках одного проекта может быть несколько контрактов). Таким образом, проектное бюджетирование сложнее классического. Более того, проекты «не умещаются» в стандартные временные отрезки: заканчивается год, но масса проектов не закончена. Зачастую сдвигаются графики выполнения. К тому же если проекты взаимосвязаны, то корректировка одного затрагивает всех остальных. Из-за того, что сроки проектов не совпадают с бюджетным периодом, возникают проблемы с отнесением затрат и доходов на соответствующий период.

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

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

«В случае портфеля проектов с большой неопределенностью можно предложить следующий подход к составлению бюджета портфеля проектов:

• Обновить бюджеты проектов, которые переходят через границу года.

• Разработать ориентировочные бюджеты для проектов, которые могут быть более или менее точно оценены.

• Сделать грубые оценки для проектов, про которые еще ничего неизвестно. Например, исходя из исторической информации о загрузке мощностей (специалистов) компании (скажем, на уровне 80 %) и выручке по проектам на единицу мощности (человеко-час). Включить их в бюджет как один или несколько проектов.

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

В принципе, можно обойтись и без прогноза проектов, про которые ничего неизвестно. Не включать их в бюджет и все. Но тогда управление портфелем усложняется: придется иметь дело с дефицитным бюджетом, где, возможно, не полностью покрыты постоянные издержки (например, административные и коммерческие расходы)»[6].

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

2.6. Консолидация финансовой информации

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

Задача консолидирования отчетности в холдингах при отсутствии единого плана счетов выливается в многоуровневый процесс документооборота. Чтобы собрать всю информацию, необходимо свести ее к единому плану счетов, что влечет за собой дополнительную работу с отчетностью. Эти манипуляции ложатся бременем на тех, кто готовит отчетность, то есть на дочерние предприятия. А материнской компании придется осуществлять программные проверки, чтобы свести подтасовку фактов к минимуму. Исключить ее полностью невозможно, так как работа ведется не с первичными данными, а с уже подготовленной кем-то отчетностью.

Обычно консолидация информации в холдингах представляет собой сложный многоступенчатый процесс. Например, дочерние предприятия самого нижнего уровня готовят отчетность и передают ее на следующий уровень. Здесь отчетность проверяют, отклоняют или утверждают. Известны случаи создания в крупных холдингах специальных отделов консолидации. В функциональные обязанности их сотрудников входит централизованная консолидация, проверка и утверждение данных, а также рассылка получаемой отчетности в подразделения, которым она необходима.

Например, в компании «Связьинвест» действует четырехуровневая структура (рис. 2.3):

1) структурные подразделения (городская телефонная станция) – несколько тысяч единиц;

2) региональные филиалы (например, Петербургская телефонная сеть) – около 80 единиц;

3) межрегиональные компании (МРК; например, Северо-Западный Телеком) – семь единиц;

4) материнская компания – «Связьинвест».

Сбор финансовой информации начинается на уровне РФ: в систему вносятся все плановые доходы, расходы и денежные поступления. Из этих сведений генерируются баланс, отчет о движении денежных средств и отчет о прибылях и убытках по каждому филиалу. Далее на межрегиональном уровне информация, полученная от РФ, вычищается от внутрихозяйственных расчетов[7] между РФ, и получается итоговая отчетность МРК. Из нее убираются внутригрупповые расчеты (ВГР) между самими МРК, и получается итоговый бюджет «Связьинвест» в разбивке по МРК. Те же самые процессы запускаются по фактическим данным.

Рис. 2.3. Четырехуровневая структура ОАО «Связьинвест»

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

2.7. Контроль и анализ

Контроль сводится к сопоставлению факта и плана. Фактические данные могут поступать автоматически из регистрирующей первичные документы системы, а могут вводиться вручную (если нет системы).

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

Задумываясь о контроле и анализе, надо понять, в чем именно вы нуждаетесь.

Основная задача контроля – выстроить правильный набор показателей деятельности компании (KPI). Очевидные и очень важные характеристики KPI:

1. Предоставление однозначной, корректной и проверяемой информации.

2. Возможность рассматриваться в разрезе различных периодов времени.

3. Раскрытие эффективности того или иного аспекта бизнеса.

4. Поддержка процесса принятия управленческих решений.

5. Возможность распознавать возникающие тренды.

Типичный, но не исчерпывающий перечень показателей коммерческой компании может быть следующим:

1. Показатели, связанные с клиентами:

1) количество новых клиентов;

2) статус существующих клиентов;

3) естественная убыль клиентов (учитывая разрыв отношений из-за убыли клиентов).

2. Оборот, сгенерированный подгруппами клиентов. Здесь могут применяться демографические фильтры.

3. Показательный баланс между подгруппами клиентов и условиями оплаты. Здесь также может применяться демографический фильтр.

4. Обзор значимых долгов в отношениях с клиентами.

5. Демографический анализ индивидуумов (потенциальных клиентов), которые могут стать клиентами: число подтвердивших, отказавшихся и рассматривающих возможность сотрудничества.

6. Анализ клиентов на предмет неоплаты в срок.

7. Прибыльность клиентов в разрезе демографических подгрупп и их разделение по прибыльности.

8. Управление компанией.

9. Информационная панель ключевых операционных показателей в режиме реального времени:

1) совокупная эффективность оборудования.

10. Посещаемость страниц сайта.

11. Отслеживание ключевых продуктов.

12. Анализ механизмов реализации (сбыта).

13. Анализ данных по реализации в разрезе различных сегментов продуктов.

14. Система показателей колл-центра.

На любом предприятии есть система показателей деятельности в том или ином виде. Как только появляется факт, бюджетная система становится поставщиком данных, в том числе для системы показателей. Популярная методология BSC (сбалансированная система показателей[8]) предписывает как минимум увязку всех имеющихся показателей в единую систему и как максимум – их сбалансированность. Исходя из практического опыта, можно констатировать, что «балансировка»[9] показателей в полной мере производится очень редко. Почему?

Потому что большинство KPI необходимы для взаимодействия между конкретными индивидуумами. Следовательно, формально они не нуждаются в увязке с KPI других пар индивидуумов. Какие это показатели? Чем больше людей находится в вашем подчинении, тем больше вы как менеджер нуждаетесь в показателях эффективности. Причем существуют базовые KPI – основные показатели деятельности менеджера: «отсутствие отклонений от бюджета», «увеличение объема реализации» и т. д. Также есть KPI роста, когда от сотрудника ждут развития. Например, фирма консультирует по вопросам легальной оптимизации налогооблагаемой базы. Дела идут успешно, и в компании начинают понимать, что могут предложить консультации, например, в области финансов: как распорядиться рабочим капиталом, чтобы добиваться такого же результата, оптимизировать налоги и максимизировать прибыль. Занимаясь налоговым консультированием, сотрудники сами становятся профессионалами в области финансов за счет опыта, полученного от своих клиентов, то есть в своей и сопутствующих областях. Опыт набирает «массу» и в определенный момент становится новой услугой. «Растущему» консультанту можно поставить следующий KPI: три раза в месяц продавать такой вид услуги, чтобы оценить ее востребованность. Это и есть KPI роста.

Методология Balance Scorecard хороша для понимания собственного предприятия. Чтобы понять бизнес-процессы компании, их можно описать, например, с помощью методологии SADT (structured analyze data technique) – изображения в виде графических элементов. Многие методологии призваны управлять, а в реальности хорошо справляются с описательской функцией. На данном этапе их использования можно остановиться. Мое стойкое убеждение, что Balance Scorecard – интересная методология, но на 100 % она не внедрена нигде. Во-первых, потому что поддерживать все показатели в сбалансированном состоянии трудно: затраты не окупаются и не приводят к ожидаемой эффективности. Во-вторых, многие просто ленятся довести дело до конца. В-третьих, второе утверждение может быть следствием третьего – людям не нужно большего. Построив и сгруппировав показатели, установив минимально необходимое взаимодействие между ними, вы просто ими пользуетесь. Этого достаточно. Вы обещаете, что когда-нибудь станете связывать еще больше показателей, вводить стратегические карты и т. д. Но зачастую ничего подобного не происходит: методология дала толчок, помогла понять, как устроено предприятие; установила новое взаимодействие начальник – подчиненный, поставив новые KPIs; дала сотрудникам возможность ощущать себя единым коллективом; вывела менеджмент на новый образовательный уровень. Все это само по себе является значимым толчком к изменению организации в целом, к повышению ее эффективности.

Лучшие мировые практики в области анализа финансовых данных выделяют следующие виды анализа:

• трендовый анализ;

• сопоставление данных разных версий;

• сопоставление данных по разным объектам;

• анализ «что будет, если…»;

• анализ показателей эффективности.

Трендовый анализ

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

1. Горизонтальный анализ статей отчета о доходах и расходах и отчета о движении денежных средств.

Проводится оценка динамики следующих показателей:

• темпы прироста доходных статей;

• темпы прироста выручки;

• темпы прироста прибыли.

2. Структурный анализ отчета о доходах и расходах и отчета о движении денежных средств.

3. Анализ вклада различных статей в бюджетные показатели.

4. Структурный анализ балансового отчета.

При проведении структурного анализа балансового отчета оцениваются следующие значения:

• изменение доли собственного капитала в сумме всего капитала;

• изменение доли текущих обязательств в валюте баланса;

• соотношение роста доли текущих активов над ростом доли внеоборотных активов;

• соотношение дебиторской и кредиторской задолженностей.

Сопоставление данных разных версий

Сопоставление данных разных версий проводится на постоянной основе путем сравнения между собой всех версий бюджетов.

Мастер-план и Факт – оценка выполнения мастер-плана. В ходе этого анализа оцениваются:

• процент выполнения мастер-плана по статьям БДР и БДДС за отчетный период;

• процент выполнения мастер-плана по статьям БДР и БДДС за прошедшие периоды года нарастающим итогом;

• доля нарастающего итога фактических данных в итоге утвержденных БДР и БДДС на год.

Также проводится анализ причин отклонений факта от мастер-плана.

В случае превышения нормативов отклонений, установленных, например, Бюджетным комитетом, инициируются изменения мастер-плана на будущий период.

Мастер-план и оперативный план – оценка возможности выполнения целевых показателей, заложенных в мастер-план. В ходе этого анализа оцениваются:

• отклонения показателей оперативного плана от показателей мастер-плана за отчетный период;

• отклонения показателей оперативного плана от показателей мастер-плана за прошедшие периоды нарастающим итогом.

Оперативный план и факт – оценка выполнения оперативного плана. Выявление тенденций и закономерностей для повышения качества планирования (снижение величины отклонений между версиями). В ходе этого анализа оцениваются:

• процент выполнения оперативного плана по статьям БДР и БДДС за отчетный период;

• оценка отклонений с точки зрения эффективности методики планирования общей суммы доходов и расходов. Эффективность методики планирования определяется топ-менеджментом компании.

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

• отклонения показателей ожидаемого исполнения от показателей мастер-плана за все периоды текущего года нарастающим итогом.

В случае превышения нормативов отклонений инициируются корректировки оперативного плана на будущий период.

Сопоставление данных по разным объектам

В рамках процесса бюджетного управления можно сопоставить плановые и фактические данные по разным объектам планирования (например, в строительстве могут сравниваться между собой строящиеся и действующие объекты). Результаты сопоставления могут быть использованы при оценке деятельности объекта и для прогнозирования деятельности на следующие периоды.

Анализ «что будет, если…»

Про данный вид анализа мы уже говорили в разделе 2.4 «Сценарное планирование». Бюджетное управление не обходится без сценарного планирования и анализа «что будет, если», которое заключается в изменении различных параметров (показателей) плана и оценке влияния данного изменения на общий плановый результат деятельности компании. В частности, для компании-ритейлера одним из таких параметров может быть количество торговых объектов, сроки ввода их в эксплуатацию, величина товарооборота, размер инвестиционных расходов. Результаты анализа могут быть использованы при выборе наиболее оптимальной стратегии развития компании.

Анализ показателей эффективности

В перечень показателей эффективности включаются как финансовые, так и натуральные показатели. Плановые и фактические значения финансовых показателей формируются на основании алгоритмов, заложенных в финансовую модель данных (см. раздел 2.8).

2.8. Финансовая модель данных

Финансовая модель данных состоит из измерений. В геометрии измерения откладываются по трем осям: абсцисс, ординат и аппликат. По аналогии создаются и финансовые измерения. Они делятся на три части: вспомогательные, базовые (временные периоды, курсы валют, типы курсов) и рабочие (план счетов, финансовая структура, номенклатурный справочник, регионы продаж, виды реализации). Каждое измерение может быть плоским и иерархическим; последнее имеет альтернативные иерархии. Что это такое? В управленческих целях вам, вероятно, понадобится рассмотреть один и тот же элемент справочника под разными углами. Допустим, есть холдинг, который состоит из нескольких организаций, и его отчетность вы хотите видеть, с точки зрения структуры юридических лиц и одновременно – линий бизнеса дочерних предприятий.

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

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

• балансовый счет;

• счет прибылей и убытков;

• счет входящих остатков;

• нефинансовый счет и т. п.

Существуют атрибуты принадлежности элементов к иерархии, например «листовое» – последнее на дереве, «родительское» – то, у которого есть дочерний элемент.

Все элементы измерения могут взаимодействовать. Понятно, что если есть родительский элемент, то он в состоянии рассчитать сумму всех подчиненных ему элементов. Это самый простой случай вычислений, который называется агрегированием.

Однако чтобы элементы начали взаимодействовать между собой, чаще требуются более сложные вычисления. Действует формула: прибыль = доходы – затраты. Прибыль находится в измерении «бюджетный классификатор». Для получения сведений в этом элементе необходимо обратиться к значениям двух других элементов – доходы и затраты. Алгоритм такого обращения необходимо четко прописать. Основные экономические показатели тоже представляют собой ту или иную формулу. Часто к формулам прибегают, чтобы облегчить процесс бюджетного планирования. Если известна арендная ставка, можно ввести элементы «количество арендуемых площадей» и «арендная ставка», а затем рассчитать статью затрат «Аренда» как их произведение.

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

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

В. Новоселов: «На каких факторах строится модель? Допустим, затраты на маркетинг составляют около 22 % выручки продвигаемых препаратов. Это модельные данные. При такой выручке затраты на маркетинг должны составлять столько-то. Следовательно, финансовый результат будет такой-то. И эта модель применима для всех подразделений».

2.9. Подводные камни бюджетирования

Бюджет как совесть: от расходов не удерживает, но вызывает чувство вины.

Неизвестный автор

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

Бюджет по бухгалтерским принципам

Бухгалтеры – люди консервативные. И если им поручено поставить на предприятии бюджетное управление, они часто стремятся бюджетировать движения по счетам бухгалтерского учета. На многих предприятиях сегодня бюджет формируется в виде дебетовых и кредитовых оборотов, «оборотно-сальдовой ведомости» или даже «шахматки» (отчетная форма в виде матрицы со счетами бухгалтерского учета на осях; в ячейках такой матрицы отражаются итоговые суммы движений денег между счетами, которые пересекаются в данной ячейке).

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

Бюджет заявок

Многие смешивают понятия «бюджетирование» и «контроль». Но это верно только в отношении бюджета затрат. Если же говорить об организации в целом, бюджетирование пересекается с контролем лишь в части проверки: насколько деятельность организации за отчетный период приблизила ее к выполнению стратегических целей. В бюджетировании отклонение – не криминал, а повод для размышления и анализа. В западном бизнесе исполнитель, у которого «есть бюджет», – это менеджер, самостоятельно принимающий решения в рамках вверенных ему средств. А в России «бюджетирование» – это зачастую просто тотальный контроль. Выглядит такой подход примерно так. «Низы» (контролируемые подразделения) составляют перечень своих пожеланий. Центр по мере сил анализирует каждую запись: кому сколько чайников и станков… Устав от скрупулезности, Центр решает: вот вам бюджет – рапортуйте, реально ли его выполнить. «Низы» подгоняют свои пожелания под спущенный сверху объем, рапортуют наверх и… считается, что бюджет сделан. В идеале (в который верят многие топ-менеджеры) все «низы» выполняют «именные» бюджеты в точном соответствии с поданными ранее заявками. Но наступает бюджетированный период, и жизнь начинает диктовать свои условия. Если заявленным заранее чайником можно пожертвовать в пользу более необходимого картриджа, кто вправе принять решение об удалении одной заявки и ее замене на другую? Хорошо, допустим, вы сверстали бюджет, который на самом деле является реестром планируемых затрат предприятия. Главная проблема теперь – собрать реестр фактических затрат и сопоставить эти два реестра между собой. Тысячи транзакций! Можно детализировать бюджет до картриджа, но делается это исключительно для его обоснования. Факт может декомпозироваться до документа, но тоже лишь для справки. Сопоставляются между собой не картридж и (купленный вместо него) чайник, а агрегированная статья затрат.

Бюджет виртуального кошелька

В практике автора встречались требования потенциальных заказчиков типа: «Недорасходованный бюджет периода накопительным итогом сохранить для следующего периода!» Эдакий переходящий и накапливающийся итог расчетов, то есть виртуальный кошелек Центра финансовой ответственности. Бюджет составляется не для того, чтобы кто-то «внезапно» сэкономил. Знаете историю про «бюджетные войны»? Война между бюджетными оптимистами и пессимистами всегда заканчивалась тем, что либо оптимисты никогда не получали премию, либо пессимисты стабильно получали ее за перевыполнение. Стоит отметить, что здесь имеется в виду период меньше года. Если же говорить о принципах формирования годового бюджета, могут применяться любые обоснованные управленческой необходимостью правила.

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

Далее, конечно, идет итерация сокращения бюджета, где финансисты оставались крайними – все сокращения со всеми согласовать невозможно. Тем более, что бюджет собирался, как мы хотели – по регламенту, в конце ноября – начале декабря. А здесь с финансистами надо его обработать: составить сложный, большой файл; все посчитать (занимало около трех недель) и выдать какой-то результат. А потом выясняется, что результат – неправильный и никому не нужный: прибыли нет, EBITDA отрицательная и т. д. Бюджет необходимо пересматривать. После этого финансисты, конечно, делали анализ бюджета; не со всеми успевали все согласовать и, естественно, были недовольные: «Мы подавали заявку на столько-то, а нас сократили, и теперь мы не можем выполнять свои обязанности». Красивая позиция из серии «отдайте мой бюджет, я его забюджетировал – потрачу, куда хочу». К сожалению, побороть такое мышление без увольнения всех его носителей и найма новых сотрудников невозможно. Но такой цели не стояло: мы стараемся действовать по мягкому варианту, то есть приучать людей».

Как избегать таких ошибок?

Если планирование и учет поставлены хорошо, контроль становится очень узкой функцией. Евгений Плаксенков сказал мне, что учет должен быть мгновенным, его не должны замечать. Планирование может занимать 99 % при условии, что на учет приходится 1 %. Контроль тоже лучше молниеносный. Если учетные формы планирования организованы верно, контроль позволяет увидеть рядом с планом факт и детализовать то, из чего этот факт сложился.

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

Чтобы систематизировать знания, полученные в этой главе, мы приводим табл. 2.5.

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

«Management accounting – это менеджмент для управления», – говорит Дмитрий Новоселов. Нет никакого подвига в том, чтобы поставить учет и вести его. Да, факт – более оперативный и детализированный, но им по-прежнему нельзя управлять.

Таблица 2.5. Связь процессов, входных данных и результатов планирования

Е. Плаксенков: «Без управленческого учета бюджетное управление – полдела. Можно начинать с управленческого учета, но тогда пришлось бы использовать процессный подход. Есть процессный менеджмент, а есть результаты. Я считаю, что в проектах лучше всего работает менеджмент, ориентированный на результат: хочу вот это и получаю».

2.10. Управленческое планирование на примере фабрики валенок

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

• Стратегическое управление.

• Сценарное планирование.

• Бюджетное управление.

• Контроль и анализ.

Стратегическое управление

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

Компания Valenki Inc. – № 1 на своем рынке. Желаемая цель – остаться № 1 на рынке обуви через пять лет.

1. Разработка стратегического плана начинается со SWOT-анализа, то есть оценки своих возможностей, сильных и слабых сторон, а также опасностей. В качестве сильной стороны бизнеса отмечается завоевание сильной популярности: при слове «валенки» все потребители сразу вспоминают фирму Valenki Inc. Опасность в том, что люди перестают носить валенки, то есть данный рынок в принципе может исчезнуть. Перспективы развития скрыты в том, что люди переходят на полимерные искусственные материалы, которые в 10 раз теплее валенок. Слабой чертой компании было признано отсутствие опыта в работе с новыми технологиями.

2. Далее руководство Valenki Inc. приступило к формулированию стратегической инициативы с учетом данных анализа. Решили, что компания должна сосредоточиться на новых материалах (то есть использовать «возможности»). Тогда нивелируется риск выхода валенок из моды (есть шанс избежать «угрозы»). А для этого надо освоить новые технологии (то есть преодолеть свои «слабые стороны»). Популярность марки («сильные стороны») позволит Valenki Inc. завоевать рынок, начав выпуск обуви из новых материалов.

Итак, стратегическая инициатива – завоевание нового рынка обуви. Чтобы добиться желаемого, следует разбить общую цель на несколько задач. Например:

1. Освоить новые технологии.

2. Повысить образовательный уровень персонала (позволит освоить новые технологии).

3. Заключить договоры с владельцами технологий.

4. Построить бизнес-план по удешевлению технологий и самого конечного продукта.

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

СМОТРИ И ПЕРЕСМАТРИВАЙ

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

Сценарное планирование

Говоря о сценарном планировании, немного забежим вперед и разграничим это понятие с бюджетным планированием. В общих чертах эти процессы похожи: целью каждого является программа действий предприятия на определенный промежуток времени. Но если в компании составление плана идет «сверху вниз», ей больше подходит сценарное планирование, а если «снизу вверх», – бюджетное управление. Об этом главном отличии нужно помнить финансовым директорам, когда они произносят слово «бюджетирование». При этом не исключено мирное сосуществование в одной фирме обоих процессов. И, наверняка, в компаниях, где все очень хорошо поставлено, так и есть. Однако с понятийной точки зрения их нужно разделять. Сценарное планирование – прежде всего бизнес-планирование ресурсов по компании в целом, которое осуществляет совет директоров, генеральный директор или директор и его первые заместители (руководители департаментов, но не отделов!).

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

2. Все планы консолидируются и передаются на рассмотрение совету директоров. Консолидированный бизнес-план дает представление о том, насколько достижима поставленная стратегическая цель. Если ясно, что собственных ресурсов недостаточно, процесс управленческого планирования идет по второму кругу – с комментариями и ограничениями по ресурсам (спущенными от совета директоров).

СОБСТВЕННИКИ ПРОЦЕССА

Образно говоря, назначение процессов сценарного планирования заключается в том, чтобы спуститься с небес на землю и понять, какими ресурсами мы обладаем, сможем ли мы прийти к намеченной цели. Самое больное место сценарного планирования – достижение консенсуса по ресурсам. Ведь если консолидированный план не отвечает возможностям компании, его приходится корректировать по второму, третьему и энному разу, чтобы в итоге получить работоспособный план. Здесь очень важно, кто будет собственником этого процесса. Потому что, хотим мы того или нет, но у каждого департамента есть своя локальная цель: департамент продаж хочет больших бонусов и меньших планов по продажам, производственники мечтают обновить оборудование, закупщику необходимо расширить склад и т. д. Чтобы минимизировать урон от локальных интересов, руководить процессом управленческого планирования должна независимая команда – совет директоров либо круг заместителей генерального директора. Главное, чтобы их целью было составление не собственного бюджета, а бюджета компании в целом. Для этого они должны регулярно собираться, и каждый – обладать правом высказать свои предложения.

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

Бюджетное управление

Бюджетное управление необходимо, когда план работы предприятия и обеспечение всей стратегии ресурсами сосредоточены на нижних уровнях организации. У каждого отдела есть свои ожидания по затратам. Причем о необходимости этих затрат осведомлены лишь они. Ну, не обязан заместитель генерального директора знать, сколько компьютеров и принтеров требуется отделу N! Покажем, как данный процесс может происходить на практике.

1. От руководителя департамента в подчиненные ему отделы спускается информация о целях и финансовом обеспечении.

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

Отделу по работе с поставщиками нужно обеспечить поставку полимерных материалов – подобрать поставщика, заключить с ним предварительное соглашение и составить график поставок. На это выделено $20 000.

2. Каждый отдел составляет план действий в соответствии с целями и имеющимся бюджетом.

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

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

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

ЗАЯВКА ЗАЯВКЕ РОЗНЬ

Бюджетное управление многим представляется как сбор заказов на ресурсы, который часто называют «заявочной кампанией». В целом так и есть, но всегда полезно дать расхожему термину более точное определение. Нередко под заявочной кампанией понимают разные процессы. Например, есть предприятия, не использующие сценарное планирование или стратегическое управление. Они раз в год разрешают всем отделам собрать все заявки, выходят на какую-то огромную цифру и директорат говорит: «В два раза меньше». И процесс идет по второму кругу. Существует еще более авторитарный метод, который и бюджетированием-то назвать нельзя: Заявки собираются на самом верху и режутся по усмотрению руководства. А отделам спускают информацию, что у них из 10 поданных заявок утверждены лишь три, и точка! Последний пример иллюстрирует важнейший момент – бюджетирование в профессиональном смысле является синонимом слова «делегирование». Начальник отдела должен сам планировать свою деятельность и понимать, почему он может потратить $50 000, а не $100 000. Если он сам спланировал, как добьется поставленной цели, используя имеющиеся ресурсы, то сможет сам и за результат ответить. А если у него безо всяких объяснений приняли три заявки из 10, никакой мотивации на работу (и, как следствие, ответственности за результат) не будет.

Преодоление преград

Есть несколько причин, почему бюджетное управление – технологически более сложный процесс, чем сценарное планирование:

• он охватывает гораздо большее количество подразделений;

• он требует «горизонтальных» согласований (например, отдела продаж с производственным отделом);

• в этом процессе нет единой команды, принимающей решение, – все отделы действуют самостоятельно;

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

• учитывая, что конкретных лиц, ответственных за свои бюджеты, в компании может быть несколько сотен, и они заявляют свои бюджеты не одновременно, а волнообразно, процесс бюджетного управления должен быть четко регламентирован: кто и когда предоставляет сведения. Этот момент – главная сложность в бюджетировании: если нет возможности получать нужные данные к определенному сроку, компания не сможет осуществлять скользящее бюджетирование (об этом подробнее – в следующем разделе), к которому переходят все современные компании.

Контроль и анализ

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

Два вида бюджета – годовой и оперативный

У начальника склада есть годовой бюджет в $100 000. Он равномерно поделен на кварталы (по $25 000 на каждый). В третьем квартале один из складов затопило, и часть помещения пришлось ремонтировать. В итоге за квартал было потрачено $35 000. Начальник склада, чтобы уложиться в годовой план, сократил расходы в четвертом квартале на $10 000: отказался от запланированного приобретения спецодежды и урезал расходы по статье «корпоративное празднование Нового года».

Скользящее бюджетирование

У начальника склада есть бюджет на четыре квартала вперед, который он ежеквартально пересматривает. На предстоящие четыре квартала в бюджете заложено $100 000, по $25 000 на каждый квартал. В третьем квартале один из складов затопило, после чего часть помещения пришлось ремонтировать. В итоге за квартал было потрачено $35 000. В начале четвертого квартала начальник склада пересмотрел бюджет на предстоящие четыре квартала (последний квартал текущего года + 3 квартала года следующего) и сократил расходы равномерно – на $2500 в каждом квартале. Ему не пришлось отказываться от запланированного приобретения спецодежды. Были сокращены только расходы на корпоративное празднование Нового года.

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

3. Постановка УУ

3.1. Разработка политики УУ

Финансовый учет а управленческий точный, но мертвый, неточный, но живой.

Неизвестный автор

Политика управленческого учета – это документ, декларирующий основные учетные принципы компании. При его создании стоит предусмотреть возникновение нестандартных ситуаций и как можно четче их прописать. Политика управленческого учета является первой инструкцией для сотрудников, приступающих к его ведению в вашей компании. В отличие от политики БУ, этот документ более динамичный, он может дополняться по мере необходимости. Однако основные учетные принципы во избежание нарушения преемственности периодов кардинально лучше не менять. Всем известен пример, когда переход от списывания материальных ценностей по методу LIFO (last in – first out – «последний к зачислению – первый к списанию») к FIFO (first-in-first-out – «первым поступил – первым продан») приводит к несопоставимости двух годовых отчетов.

Политика управленческого учета состоит из тех же пунктов, что и политика БУ. Поэтому многие компании в политике УУ просто перечисляют ее отличия от БУ. На некоторых из них мы остановимся подробнее.

1. Политика бухгалтерского учета предназначена для главного бухгалтера и генерального директора. А ПУУ интересует более широкий круг лиц и гораздо большее количество сотрудников должно ей следовать. Чем выше статус документа ПУУ, тем легче пройдет внедрение.

2. В ПУУ должны быть прописаны правила осуществления операций, которые расходятся с ПБУ. Например, регистрация неотфактурованных операций, начислительных проводок, когда без подтверждающего документа можно внести условную запись на основе имеющейся информации (товар поступил), а при получении первичных документов – подтвердить ее. Вероятно, в УУ вам потребуется отражать проводки по подписанным контрактам, размещенным заказам на закупку и т. п. Иногда возникают ситуации, при которых в отчетности текущего периода необходимо отобразить операцию, фактически относящуюся к текущему отчетному периоду, но которая реально будет проведена в следующем. Например, отображение в текущем месяце расходов на заработную плату, физически начисляемую и выплачиваемую в первых числах следующего месяца.

3. Предварительная отчетность. В политике бухгалтерского учета указано, что компания отчитывается ежеквартально на основе всех первичных документов. ПУУ может декларировать, что отчетность осуществляется в два захода – предварительный и финальный. В ПУУ необходимо прописать, как формируется предварительная отчетность (такой-то отчет создается первого числа каждого месяца). Можно поставить ограничение, что отчет формируется, не дожидаясь первичных документов. Если вы ввели понятие «неотфактурованные данные», перед генерацией такого отчета нужно занести все неотфактурованные операции.

4. Отражение документов и фиксация проводок. Рассмотрим ситуацию, когда в отчетный день осуществляется регистрация документов, но из-за болезни финансового директора не все операции, которые относились к сегодняшнему дню, были проведены. Поскольку баланс уже сформирован и управленческие решения по нему приняты, следует четко прописать, как нужно относиться к проводкам такого рода. Есть, например, счет, обязательный к оплате в течение пяти дней: одно дело, если он внесен сегодня, и другое, если его занесут завтра. Так как это влияет на все последующие расчеты платежного календаря, правильнее фиксировать подобные документы днем, которым они проведены; особенно, если в компании применяется автоматизированная система регистрации всех операций, которая позволяет автоматически же создавать план платежей, график поступлений и выплат, ежедневный cash flow и сами платежи. Это достаточно тонкий момент – определить, что первично. Некоторые учитывают процент погрешности, который также должен быть прописан в ПУУ. Так, недопустимо из-за недовнесения операций ошибиться на 5 % выручки – ведь такая цифра уже сопоставима с нормой рентабельности.

5. ПУУ придает статус определенным событиям, данным и документам. В ней может быть прописано, что основным отчетом, предназначенным для анализа руководством компании, является проверочный баланс, сгенерированный в 8 часов утра каждого рабочего дня (или обороты компании по конкретным счетам, или проверочный отчет на первое число каждого месяца, созданный в 15:00, и т. п.). Присваивая статусы тем или иным учетным событиям, необходимо описать роль автоматизированной системы (если таковая внедрена или ее внедрение планируется). Например, в компании используется Microsoft Dynamics АХ. Приказом должно быть закреплено, что это официальная система, в которую все сотрудники заносят авансовые отчеты; проекты учитываются в MS Project; анализ проводок – в Palo. Данные в Microsoft Dynamics АХ или в 1С вносятся на момент появления документа. При этом необходимо указать в политике временные рамки учета документа: на дату реального осуществления операции или на дату совершения учетного события. Сведения в Palo транслируются на ежедневной основе (в определенное время или в режиме он-лайн). Все эти базовые принципы также следует отразить в ПУУ.

6. Стандарт ПУУ. Часто в качестве стандартов управленческого учета берутся стандарты МСФО, поскольку они достаточно тщательно проработаны. К тому же чем раньше вы освоите МСФО, тем легче вам будет со временем подготовиться к IPO. Организовав у себя УУ по стандартам МСФО, компания де-факто готовится к плавному переходу на международные стандарты бухгалтерской отчетности. Также существуют стандарты управленческого учета (management accounting), на которые можно ориентироваться (есть разные школы, методики и принципы; если нужно взять за основу общепризнанные стандарты УУ, предпочтительнее US GAAP: Generally Accepted Accounting Principles).

7. В российских компаниях превалирует обращение к стандартам МСФО. Это может быть и микс – в части учета затрат использовать рекомендации management accounting, а для отчетной части по предприятию в целом – стандарты МСФО. При разработке политики УУ полезно изучить требования закона SOX. При размещении акций на американских биржах вам придется следовать положениям этого закона и подвергаться независимому аудиту. Так что лучше заранее обеспечить соответствие всех процессов получения отчетности международным требованиям.

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

9. Учет основных средств. Разница заключается в принципе амортизации основных средств. В России процесс амортизации зависит от отчетности перед государством. Уменьшение стоимости и закладывание средств на возобновление можно осуществлять за счет налогооблагаемой базы. Но как собственники мы можем формировать дополнительный фонд на возобновление из чистой прибыли. Например, амортизация здания. Нет смысла полагаться только на резервирование средств по бухгалтерскому принципу, потому что через 10 лет здание придет в негодность. В данном случае фонд на возобновление необходимо сформировать быстрее. Лучше выбрать другой алгоритм для расчета амортизации в целях управленческого учета. Бывает и все наоборот: изделие служит очень долго, по бухгалтерскому учету его не списать, а по управленческому учету уже пришло время.

10. При материальном учете возникает отличие, обусловленное целесообразностью. В бухгалтерском учете отсутствует понятие «готовые (выполненные) работы»: изделие учитывается только на основании документа. Возьмем пример из сферы строительства. Сколько кирпичей и бетона отвезли на стройку, говорится в накладных, которые поступают в бухгалтерию. Однако в терминах, понятных собственнику, кроме информации о замороженном количестве стройматериалов и денег, бухгалтерия ничего сказать не может. Из бухучета топ-менеджмент не почерпнет сведений о текущем состоянии дома. А его интересует, например, сколько домов возведено на 50 % в стоимостном выражении.

11. В политике БУ нет понятия goodwill – увеличение оценки бизнеса, его стоимости в той мере, в какой этому способствуют репутация, авторитет фирмы и другие трудноопределимые, «неосязаемые» факторы. Goodwill рассматривают как нематериальный актив. Он отражает способность компании в целом получить больше прибыли, чем если бы она просто продала свои активы.

12. В ПБУ и ПУУ могут по-разному учитываться ценные бумаги; кредиторская и дебиторская задолженности. Например, разнятся сроки списания задолженности.

13. Большим разделом политики УУ является описание консолидации сведений всех входящих в холдинг компаний (дочерние или ассоциированные фирмы). Естественно, данный процесс осуществляется согласно стандарту, признанному материнской компанией. Но у каждой «дочки» – своя специфика бухгалтерского учета, некоторые могут не вести у себя УУ. Поэтому необходимо прописать, как их учетные данные будут интерпретироваться головной компанией. Этот раздел станет руководством для подготовки отчетности дочерними предприятиями, должен включать информацию о периодичности консолидации и сроках предоставления отчетов.

14. Калькуляция прибыли. В бухгалтерском учете расчет прибыли строго регламентирован. А в УУ используются понятия «ожидаемая прибыль», «запланированная прибыль», «прибыль без учета расчетов с партнерами или ассоциированными компаниями» и т. п. Политику приобретений других фирм и различия в учете соответствующих затрат необходимо прописывать, если компания заранее планирует подобный способ «неорганического» роста. Для сделок M&A часто требуются кредиты, а они по-разному учитываются в российском учете и в УУ. Возможна ситуация, когда до 20 % оборота предприятия списывается в одном из учетов, а в другом учете списание осуществляется постепенно (бывают случаи, когда в отчетности по УУ компания получила прибыль, а по российскому учету терпит убыток).

Е. Плаксенков: «На проработку учетной политики управленческого учета мы потратили больше всего времени. Я твердо настаивал на управленческом учете по международным стандартам финансовой отчетности. Не надо ничего выдумывать! В результате появился толстый фолиант, посвященный управленческому учету. В процессе разработки разворачивались настоящие баталии. На два месяца произошла задержка лишь из-за того, что пытались доказать необходимость отклониться от международных стандартов, поскольку наш бизнес слишком уникален.

Например, отчет о покупаемых для продажи квартирах. Для меня это – товарные запасы. Согласно РСБУ, если ты купил квартиру, должен показывать ее в разделе «основные средства». Строишь поселок – основные средства, то есть необоротный актив. Но для нас это – товар. Какая разница, сколько он создается? Подводная лодка строится два года, поселок – семь лет. Но если это – товар, в конечном итоге рассматривать его нужно в разрезе капитала. Это работающий капитал со своим определенным свойством ликвидности и т. д.; инструмент работающего капитала. По МСФО, как и согласно управленческому учету, большую долю занимает учет рыночной стоимости товара. Международные стандарты формировались более 500 лет. Над ними бились лучшие финансисты мира. Они столько версий создали, чтобы остановиться на том, как учитывать проценты, куда их относить, где позволить рекомендовать один путь, а где дать возможность нескольким способам учета. Почему надо полагаться на мнение консультантов, у которых первый или даже 30-й проект, и при этом отказываться от 500-летнего опыта? Посчитайте, сколько финансистов за это время формировали принципы учета? Поэтому наша учетная политика в управленческом учете построена на международных стандартах».

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

О. Урнев: «Может ли существовать политика управленческого учета, схожая с политикой бухгалтерского учета? Таким же образом прописанная и детализированная? Наверное, нет. Потому что она – очень гибкая. Мы сами за два года работы не раз меняли форматы и количество отчетов и отслеживаемых при помощи управленческой отчетности точек. Если бы мы сели за написание правил управленческого учета в 2006 году, они изменились бы уже к моменту завершения этой работы. И так можно было переделывать до бесконечности. Безусловно, инструкция должна быть, но это инструкция, а не политика, не система. Она не накладывает жестких обязательств. Это руководство – что должен сделать пользователь для отражения тех или иных данных.

Управленческая отчетность возникает, исходя из задач сегодняшнего дня. Они неким образом коррелируют со стратегическими целями, годовыми, трехлетними и десятилетними планами. Но их описание, наверное, замедлит саму управленческую отчетность, лишит ее всякого смысла. Это должно быть в голове у основных руководителей предприятия, которые каждый день требуют эту отчетность и довольно часто ее меняют. Я понимаю: у подчиненных часто возникает ощущение, что руководитель опять изменил отчетность, так как этого захотела его левая пятка. Но это нормально. Если руководитель не знает, что ему надо, – вот это действительно плохо. Осознанное изменение требований к управленческой отчетности объяснимо, потому что все меняется. А управленческая отчетность бьет в те болевые точки, которые должны устраняться. Так и происходит. Но, к сожалению, на их смену приходят другие проблемы».

Б. Рябов: «Все отчетности, которые мы формируем, готовятся, естественно, по политикам. Это всегда требовалось и было важно. А тот факт, что получатели данной информации – разные, отражается на процессах: как готовить – русскую отчетность и отчетность по МСФО. Надо понимать, что мы имеем дело с экономической материей, начинать в учетных политиках со сбора проводок и заканчивать перекладками и консолидацией.

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

Все зависит от зрелости приобретаемых компаний в определенный момент времени: все поля деятельности и бизнес-активности не бывают покрыты одинаково с точки зрения учета. Конечно, для отчетности процесс консолидации каждой покупаемой фирмы с холдингом начинается сразу с момента ее приобретения. Но нужно какое-то время, чтобы подтянуть новую компанию до нашего уровня, реализовать проекты по сбору и обработке учетных данных. Кроме того, учетная политика для целей бухгалтерского учета формально зафиксирована в течение года (требование законодательства). Соответственно переходный период, в течение которого учетные политики внутри компании расходятся, неминуем».

3.2. Постановка планирования

Стратегические сессии

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

Прежде всего в компании нужно выделить структурную единицу, ответственную за реализацию стратегии – Отделом Управления Стратегией, о котором мы говорили с вами в разделе 2.1. Стратегическое планирование.

День первый и второй: формирование команды

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

Неделя: подготовка

Примерно неделю после такого kick-off проектная группа посвящает подготовке к главному событию проекта – семинару топ-менеджеров, или первой стратегической сессии. Ваши представители согласуют с топ-менеджментом даты мероприятия, а консультанты изучают существующую стратегию и систему показателей (если таковые на данный момент имеются).

Два самых важных дня: семинар топ-менеджмента в глухой тайге

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

Первый день сессии

1. Рабочая группа вместе с вами проводит «проектное целеполагание». Понятно, что есть договор с целями, устав с рамками и приказ с идеей нового проекта. Но

все это – формальности. Теперь нужно достичь понимания: что именно хочет и получит каждый директор или заместитель генерального директора от данного проекта.

2. Проводится ознакомление с теоретическими основами наиболее распространенных методик стратегического управления: ССП, Шесть Сигма, MBO и т. п. Какие бы степени MBA ваши руководители не имели, очень важно, чтобы все методики – «претенденты» были освежены в их памяти и представлены в виде стройной справочной системы. Одна из самых серьезных проблем стратегического планирования – как связать измеряемое с неизмеряемым. Проверенное средство в данном случае – научить топ-менеджеров основам стратегического управления. Математическим, а не идеологическим аспектам этой науки. Поняв, как работать с «весами», «категориями» и «вкладами» показателей, с балансировкой, скованный страхом перед проблемой менеджер как минимум перестает бояться, а как максимум – становится ярым сторонником системы стратегического управления.

3. Затем рабочая группа может провести обзор инструментальных средств. Помимо Excel, в их список обязательно должны входить как системы стратегического управления, направленные на разработку стратегии, так и системы «дэш бордин-га» – инструменты, нацеленные на создание ключевых показателей эффективности (см. главу «Технологическая поддержка УУ»). Если обзор проводят консультанты, несомненно, у них будут свои продуктовые предпочтения. Но если они не могут аргументированно раскрыть природу своих предпочтений, поверить в их рекомендации подчас трудно. Здесь важно также затронуть вопрос связи обозреваемых продуктов с системами учета и бюджетирования.

4. В заключение первого дня рабочая группа представляет вам действующую систему стратегического управления, то есть вашу миссию, стратегические цели, инициативы, показатели – в их нынешнем состоянии. Цель такой презентации – стимулировать мозговую деятельность руководства для развития системы стратегического управления из точки «как есть» в точку «как должно быть». Начинается реальный мозговой штурм, переходящий из комнаты семинара на природу, в кулуары и/или в бар. Руководители пытаются заполнить пустующие пространства вашей стратегической модели – нарастить «обрубленные» ветви (стратегические инициативы), листочки (показатели) или целые стволы (стратегические цели). По сути, разговоры становятся выполнением домашнего задания. Ибо каждый участник такого мероприятия получит свое домашнее задание и постарается максимально полно выразить то, чего именно ему не хватает в существующей модели стратегического управления для его директорской работы.

Второй день сессии

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

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

3. Вторая половина второго дня посвящена индивидуальным беседам консультантов и топ-менеджеров, чтобы они достигли максимального понимания: как будет работать их организация с новой системой стратегического управления.

Следующая неделя: действует рабочая группа

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

Еще неделя: достучаться до среднего звена

Следующий шаг – семинар или серия семинаров для менеджеров среднего звена. Их главные цели:

а) ознакомление с проектом стратегической модели верхнего уровня;

б) ознакомление с методикой (комплексом методик) разработки модели;

в) разработка планов по развитию стратегической модели верхнего уровня до следующих уровней.

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

Последняя неделя

Последнюю неделю (или две – не больше!) вы должны потратить на:

а) окончательную доработку стратегической модели верхнего уровня по результатам семинаров для «мидл-менеджмента»;

б) доработку или разработку регламентов сбора информации для ключевых показателей первого уровня (далее – регламенты);

в) формализацию плана развития стратегической модели верхнего уровня;

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

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

И помните: стратегические сессии необходимо проводить минимум два раза в год. Все последующие сессии можно организовывать в более сжатом формате. Например, половина рабочего дня.

Пример плана «прорывного» проекта – «Стратегическая сессия № 1».

Таблица 3.1. Стратегическая сессия

Постановка бюджетного управления

Система бюджетирования или система бюджетного управления (СБУ) не может появиться и существовать без методологии бюджетирования. Она должна отвечать на вопросы: «кто?», «что?» и «как?»

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

«Что?» В рамках методологии готовится реестр бюджетных показателей. Это не просто план бухгалтерских счетов, а перечень показателей, по которым руководство контролирует исполнение бюджетов. Важно иметь в формализованном виде и сами отчетные формы представления показателей.

«Как?» Описание методологии бюджетирования сводится в регламенты составления бюджетов, где указано, кто, что, в какой последовательности и к какому сроку составляет, согласует, контролирует и анализирует.

Далее в этой главе приводятся описания документов, в совокупности своей представляющих собой методологию бюджетного управления:

1. Положение о бюджетном управлении и контроле.

2. Финансовая структура.

3. Предварительная модель данных.

4. Регламент бюджетного процесса.

Полные версии этих документов, разработанные в свое время для конкретных клиентов, вы сможете найти на прилагаемом к Руководству CD.

«Положение о финансовой структуре» приведено в разделе 6.2 главы 6 Руководства.

3.2.2.1. Положение о бюджетном управлении и контроле

Целью данного положения (см. пример в разделе 6.2 главы 6) является описание процедуры составления бюджетов, их консолидации, анализа, пересмотра и утверждения.

Как и любой другой постановочный документ, оно должно раскрывать основные используемые понятия, сокращения и термины.

Положение состоит из следующих разделов:

I. Цели и задачи бюджетирования

Смысл этого раздела заключается в том, чтобы выразить в письменной форме то, зачем вашему предприятию необходимо бюджетное управление. Разница между целями и задачами в том, что задачи описывают конкретные действия и методы, которые будут предприняты для достижения целей. Цели же введения бюджетного управления могут (зачастую так оно и есть) отличаться от целей введения УУ в компании. Бюджетное управление, в свою очередь, является средством достижения целей введения УУ. Их формулирует собственник, руководствуясь требованиями текущего состояния бизнеса. Например, целью введения УУ может быть повышение управляемости бизнеса в целом. На языке собственника это может означать следующее: «Моя компания выросла, и я не могу больше управлять всеми процессами сам. Необходимо делегировать полномочия». А делегирование, как мы уже неоднократно повторяли, во всех управленческих теориях накрепко ассоциируется с бюджетированием. Поэтому внедрение системы бюджетного управления может быть заявлено как средство достижения цели введения УУ в компании. То есть внедрение бюджетного управления – задача, выполнение которой необходимо для достижения цели введения УУ.

II. Основные принципы бюджетирования

Согласованность с учетной политикой. Если на предприятии действует политика управленческого учета, об этом необходимо сказать в данном разделе. Другим примером может быть согласованность бюджетного управления с политикой учета по стандартам

МСФО.

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

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

Принцип регламентации. Приводится ссылка на документ «Регламент бюджетных процессов компании» (см. 3.2.2.4).

Периодичность и горизонты планирования. Приводятся основные используемые в бюджетном управлении периоды и горизонты планирования. Более подробно они расписываются в приложении к версиям планов.

Принципы отражения плановых и фактических данных. Основная цель данного раздела – декларативная. Не забывайте, что положение о бюджетном управлении и контроле будут читать все участники процесса. Для них необходимо лишний раз отмечать даже вполне очевидные вещи. Например, что для сопоставления фактических и бюджетных сведений фактическая информация должна быть представлена в том же виде, что и бюджетная. Значит, при учете должны использоваться те же аналитические признаки (ЦФО, периоды и пр.). Кроме того, основные принципы учета факта должны совпадать с принципами планирования в компании, за исключением описанных в разделе допущений (при учете фактических данных допущения не используются).

Версионность планирования и контроля. У каждого корпоративного плана всегда есть несколько версий (например, стратегический план, генеральный план, оперативный план, платежный календарь, факт, ожидаемое исполнение). Описываются типы и природа данных, составляющих каждую версию. Нужно описать, кто ее утверждает и формирует, с какой периодичностью и как при необходимости одна версия плана трансформируется в другую.

Аналитические признаки. Приводится ссылка на соответствующее приложение к положению о бюджетном управлении и контроле.

Валюта отчетности и ввода.

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

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

Принципы анализа данных. Перечисляются основные методики, которые предполагается использовать при анализе данных бюджетного управления (трендовый анализ; сопоставление данных разных версий; сопоставление данных по разным объектам; анализ «что будет, если…»; анализ показателей эффективности и т. п.).

III. Финансовая структура компании

Ссылка на соответствующее приложение к Положению о бюджетном управлении и контроле.

IV. Бюджетная модель компании

Во введении к этой главе описывается:

• перечень блоков бюджетирования каждого уровня холдинга, а также уровня консолидации, если бюджетное управление внедряется в холдинговой структуре;

• общие допущения;

• перечень объектов планирования по каждому блоку с указанием должностей ответственных за планирование и контроль.

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

V. Общая схема бюджетного процесса

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

VI. Список приложений

Настоящее Положение не может рассматриваться отдельно от следующих приложений:

1. Классификатор бюджетных статей.

2. Финансовая модель данных в формате MS Excel (форматы бюджетов, алгоритмы расчетов, соответствие бюджетов и ЦФО).

3. Лист согласования.

3.2.2.2. Проектирование финансовой структуры

Практика

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

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

Обычно ответственность распределяет первый руководитель. Финансовый директор вводит новые понятия, доказывает их необходимость и в конечном итоге влияет на управление компанией, объясняет менеджменту цели и задачи, озвучивает понятные всем принципы и составляет набор регламентов, положений, СОПов (стандартных операционных процедур), подробно регламентирующих все бюджетное управление.

В нашей компании руководитель распорядился ввести финансовую структуру, только получив на руки пакет объяснительной документации. Принцип финансовой структуры у нас заключается в том, что все многоуровневые решения по всем ресурсам фирмы может принимать лично генеральный директор. Однако из-за нехватки времени он не может это делать лично и поэтому делегирует некоторые обязанности своим заместителям. Они, в свою очередь, могут делегировать принятие каких-то решений своим заместителям и т. д., вплоть до начальников самых маленьких подразделений. При этом изначально структура принятия решений делилась на две части. В управленческом учете существуют понятия ЦФО и ЦФУ. При введении финансовой структуры я их специально развел – отбросил ЦФУ[12] (центр финансового учета), чтобы оно не запутало людей (ЦФО и ЦФУ звучит почти одинаково; на первых порах многие бы путались), и использовал МВЗ – место возникновения затрат. Кроме того, в термине ЦФУ заложено противоречие – не будет начальник цеха что-то учитывать и потом отчитываться перед правлением. На реальном производстве этого никогда не происходит. Можно, конечно, каждому центру финансового учета нанять экономиста. Но лучше без этого обойтись. Мы пошли по другому пути: определили, что в этой точке возникают затраты, и что она – самая маленькая составляющая финансовой структуры. ЦФО принимает решение и несет за него ответственность, а ЦФУ – место возникновения самих затрат. У каждого центра финансовой ответственности существует одно или несколько МВЗ. Меньше одного быть не может, потому что центр – руководитель, а у каждого руководителя есть зарплата, секретарь, канцелярия, водитель и т. д. Мы построили свою финансовую структуру на этом принципе и пользуемся ею уже четыре года. По сути, она двухуровневая – ЦФО и МВЗ. При этом у нас четыре уровня центров финансовой ответственности в зависимости от уровня принятия решений и ответственности за бюджет:

1. Общий уровень – генеральный директор и совет директоров.

2. Второй уровень = уровень директоров – функциональные директора и директора предприятий.

3. Третий уровень – уровень их заместителей.

4. Четвертый уровень – заместители заместителей.

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

Теория

Финансовая структура представляет собой исполнительный механизм бюджетного управления. Чтобы описать и утвердить финансовую структуру компании, разрабатывается Положение о финансовой структуре. Целью данного документа является описание центров финансовой ответственности, построение их иерархии, определение степени финансовой ответственности структурных единиц за производимые действия.

Основные разделы, которые необходимо осветить:

I. Принципы формирования финансовой структуры.

II. Структура центров финансовой ответственности.

III. Полномочия и ответственность.

IV. Целевые показатели и показатели эффективности.

I. Принципы формирования финансовой структуры

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

Финансовая структура создается на основе организационной. Один из первых пунктов – выделение центров финансовой ответственности и их классификация по типам:

• центр инвестиций;

• центр прибыли;

• центр дохода;

• центр маржинального дохода;

• центр затрат;

• центр дохода и затрат.

II. Структура центров финансовой ответственности

После отнесения объектов к конкретному типу ЦФО определяются их уровни подчинения – формируется иерархия в зависимости от целей и задач планирования и контроля. В этом разделе публикуются таблицы, в которых наглядно отображено распределение центров финансовой ответственности по уровням и типам.

III. Полномочия и ответственность

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

IV. Целевые показатели и показатели эффективности

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

Помимо целевых, есть показатели эффективности, которые получают из систем учета, бюджетирования и др. Они предназначены для оценки эффективности деятельности ЦФО и включают как финансовые, так и нефинансовые показатели.

Разработанный перечень показателей, где могут быть ROI, EBITDA, рентабельность продаж и иные, формируется в виде таблицы для всех ЦФО. Также в ней уточняется принцип расчета каждого показателя. Например, качество обслуживания, оценка показателя происходит на основании анкет, заполненных покупателями.

Приложения

В приложениях размещаются схемы финансовой структуры.

3.2.2.3. Проектирование предварительной модели данных

В разделе 2.8 «Финансовая модель данных» главы «Управленческое планирование» мы рассказали о том, что такое финансовая модель данных. С технологической точки зрения о модели можно узнать в главе «Технологическая поддержка управленческого учета». Оба описания относятся к многомерному представлению модели данных. Такой вид идеален для использования; его можно получить в специализированных компьютерных системах. Но чтобы к нему прийти, необходимо разработать предварительную модель данных в среде электронных таблиц, например в Excel.

Пять причин использовать на стадии проектирования электронные таблицы:

1) самый удобный инструмент для работы с табличными данными;

2) можно установить взаимосвязь показателей;

3) при желании можно проверить математические расчеты вычисляемых показателей;

4) можно (и даже нужно) провести взаимоувязку показателей;

5) при последующей автоматизации удобно «перекачать» имеющиеся классификаторы и отчетные формы в автоматизированную систему.

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

Требуйте от консультантов взаимоувязанные между собой классификаторы, показатели и отчетные (бюджетные) формы, сформированные в среде общеизвестных электронных таблиц – Excel или Calc.

Предварительная модель данных представляет собой книгу электронных таблиц, содержащих следующие группы таблиц:

1) бюджетный классификатор (перечень счетов с наименованиями и кодами);

2) справочники (дополнительные классификаторы, а также типы, нормативы и базы распределения);

3) бюджетные формы;

4) пояснения к наиболее сложным формам.

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

Рис. 3.1. Схема формирования бюджета расходов и доходов

Для наглядности приводим содержание такой книги таблиц:

Главным критерием завершенности предварительной модели является то, что ею можно пользоваться как инструментом бюджетного управления. Конечно, использование электронных таблиц в масштабах компании при наличии более 10 ЦФО не эффективно (причины будут раскрыты в главе 4 «Технологическая поддержка управленческого учета»). Но если ваша Excel-модель может быть использована хотя бы в рамках финансового отдела и вы протестировали эту возможность на одном из бюджетных периодов, значит, модель построена корректно, и значительных проблем на стадии ее перевода в реальную промышленную систему бюджетного управления возникнуть не должно.

3.2.2.4. Регламент бюджетного процесса

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

II. Принципы выполнения процесса бюджетного управления

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

Принцип определения ответственности

Теория управления по центрам ответственности требует первоначального составления списков:

1) ЦФО, которые предоставляют бюджетные данные;

2) ответственных за согласование и утверждение бюджетных данных;

3) принимающих решение о платежах, превышающих бюджетные значения статей;

4) ответственных за предоставление фактических данных.

Принцип последовательности

Декларирует поэтапное получение бюджетных данных. Сама последовательность формирования бюджетов описывается в пункте IV.

Принцип итерационности

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

III. Структура управления процессом бюджетирования

Управление процессом бюджетирования осуществляется на основании утвержденной финансовой структуры, формирование которой описано в разделе 6.2 в «Положении о финансовой структуре».

Первоначально указываются подразделения, которые принимают участие в бюджетном процессе, например:

1. Центры финансовой ответственности (ЦФО).

2. Финансовые департаменты группы.

3. Бюджетный комитет.

4. Наблюдательный совет.

Состав каждого подразделения далее раскрывается подробно.

1. Необходимо дать определение ЦФО (что понимается под этим обозначением), а также привести полный список бюджетов и центров ответственности в приложении. Кроме функции заполнения собственных бюджетов на некоторые ЦФО возлагается функция согласования бюджетов других (подчиненных или смежных) ЦФО.

• Финансовые департаменты. Нужно перечислить их функции, которые по большей части сводятся к контролю составления бюджетов ЦФО и проведению план-факт анализа.

• Бюджетный комитет отвечает за согласование, контроль и утверждение бюджетов компании. Обычно в него входят контролеры, ответственные за бюджетный процесс в целом, а также, в случае с холдингом, топ-менеджеры дочерних компаний. В функции бюджетного комитета, помимо разработки регламента бюджетного управления, входит установление целевых показателей и величины допустимых отклонений фактических значений от плановых.

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

IV. Этапы процесса бюджетного управления

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

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

Этап 1. Определение целевых показателей и стратегии развития компании

Первый этап, с которого начинается весь бюджетный процесс. Глава открывается назначениями:

• периода формирования стратегии и целевых показателей;

• ответственных за этот процесс;

• момента вступления в силу целевых показателей.

Сам перечень целевых показателей приводится в «Положении о финансовой структуре». Возможно, стоит выделить приоритетные показатели и предусмотреть процедуры реагирования, если этот показатель превышает или не достигает необходимого уровня. Например, в ритейле важное значение имеет показатель Debt/EBITDA. Если после формирования бюджетов обнаруживается дефицит денежных средств, который превышает задолженность по кредитам и займам (Debt), расширенный комитет пересматривает бюджеты. Если же задолженность, напротив, перекрывает дефицит, расширенный комитет решает, как распорядиться этими средствами.

Этап 2. Формирование стратегического и генерального планов

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

• календарь выполнения всех этапов процесса (с отсылкой к таблицам, где описан принцип составления календаря);

список ответственных за каждый этап лиц с указанием Ф.И.О. и должности.

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

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

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

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

Такая структура работ применима и к другим объектам планирования.

Далее описывается поэтапное формирование стратегического и генерального планов:

• установление целевых показателей;

• заполнение руководителями бюджетов для соответствующих групп объектов или проектов;

• согласование;

• формирование консолидированных бюджетов на основании всех утвержденных бюджетов;

• определение объема требуемых инвестиций;

• коррекции бюджета в случае недостатка средств;

• повторная консолидация основных бюджетов после внесения изменений в бюджет;

• согласование и утверждение бюджета.

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

Этап 3. Формирование оперативного плана

По аналогии с генеральным планом для оперативного плана прописываются сроки и регламент его формирования с указанием ссылок на перечень используемых бюджетных форм.

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

Описание формирования плана включает следующие этапы:

• заполнение бюджетов ответственными в разрезе тех статей, за которые они подотчетны;

• дополнение, корректировка и согласование бюджетов текущих расходов центрами финансовой ответственности;

• ЦФО центрального офиса согласуют и утверждают бюджеты региональных офисов;

• ответственные согласуют бюджеты, прошедшие утверждение ЦФО на этапе 3;

• определение требуемого объема инвестиций, на основе которого осуществляется корректировка бюджета;

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

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

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

Этап 4. Формирование платежного календаря

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

Этап 5. Исполнение

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

Этап 6. Контроль и анализ

Параллельно с исполнением осуществляется контроль и анализ деятельности. В рамках бюджетного управления вводятся понятия основного и текущего контроля.

Основной контроль предназначен для анализа исполнения генерального плана. Он ведется по отчетам, которые включают следующие результаты:

• трендовый анализ;

• сопоставления генерального плана и факта;

• другие.

Текущий контроль предназначен для анализа исполнения оперативного плана. Контроль осуществляется на основе отчетов, которые включают в себя следующие результаты:

• сопоставления оперативного плана и факта;

• сопоставления оперативного плана и генерального бюджета.

Принципы проведения текущего и основного контроля описываются в «Положении о бюджетном управлении».

Оперативный контроль выполняют сотрудники финансовых департаментов. Он предназначен для контроля за выплатами на основании платежного календаря. Сотрудники финансового департамента могут перераспределять запланированные ЦФО выплаты по периодам в соответствии с остатками денежных средств и текущими приоритетами.

Этап 7. Пересмотр генерального плана

Генеральный план пересматривается при наличии объективных причин, которые необходимо обозначить (например, превышение допустимых отклонений плана от факта). В этом случае процедура пересмотра генерального плана совпадает с процедурой его согласования по перечню этапов. То есть помимо указания причин, необходимо описать процедуру пересмотра; обозначить требования к порядку и срокам выполнения задач; определить, кто отвечает за пересмотр плана. Генеральный план, подлежащий пересмотру, остается в силе до тех пор, пока не будет утвержден его новый вариант.

V. Регламент определения показателей эффективности

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

VI. Ответственность за составление, утверждение и исполнение бюджетов

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

Чтобы определить ответственных за исполнение бюджетов, необходимо использовать перечень ответственных по ЦФО из документа «Положение о финансовой структуре» и перечень бюджетов из «Положения о бюджетном управлении». Нормы отклонений и меры воздействия могут устанавливаться ежегодно.

Д. Новоселов: «У нас есть такое понятие – СОП – стандартная операционная процедура. Это то же самое, что положение или регламент. Таких документов много. Все, что касается платежей, описано «от и до», потому что платежи затрагивают всех. Все руководители ЦФО, так или иначе, являются их инициаторами: они либо подписывают, утверждают и визируют, либо сами инициируют. Причем они не принимают незакодированные документы. Даже на согласовании договоров всегда указывается, как минимум, место возникновения затрат и название препарата или кода проекта. Если статья расходов неизвестна или эта графа не заполнена, договор может вернуться. У нас действует такая многоуровневая система. Например, МВЗ: код статьи расходов есть, а кода проекта нет, потому что эти расходы к проекту отнести нельзя; то есть они непроектные».

3.2.2.5. Ошибки при постановке бюджетного управления

Если две ошибки не принесли результата – испробуй третью.

Лоренс Питер

Виды ошибок

• Ошибки при организации проекта построения системы бюджетирования

• Ошибки методические

• Ошибки при автоматизации

• Ошибки организационные

• Ошибки на стыке с другими контурами планирования

Ошибки при организации проекта внедрения системы бюджетирования

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

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

Как избежать? Управлять внедрением бюджетирования как проектом. Причем не технологическим, а управленческим, требующим глубоких изменений в поведении сотрудников.

Ошибки методические

Не внесены необходимые изменения в систему управленческого учета Последствия. Существующая модель управленческого учета может не поддерживать аналитику бюджетную. А планирование в сложившейся аналитике УУ оказывается неудобным. Сопоставление плана и факта оказывается проблематичным. Кроме того, при планировании возможны упрощения, сопоставление факта с планом может оказаться по ряду статей бессмысленным. Несогласованность плановой и учетной систем ведет к росту трудозатрат на их поддержку.

Как избежать? Надо добиться сопоставимости УУ и бюджетной модели, разработать методики планирования и сбора факта по каждой статье одновременно с разработкой бюджетной модели.

Методики планирования статей и их связь с учетом не описаны письменно Последствия. Невозможно разобраться, кто и что имел в виду, планируя данную статью. Замена людей делает невозможным анализ план-факт. Возникает путаница с распределением ответственности за реализованные методики.

Как избежать? Фиксировать все решения в нормативных документах. Если решения невозможно формализовать сразу, целесообразно фиксировать решения во временных накопителях информации (например, в реестрах), а затем утвердить необходимые стандарты и регламенты.

Бюджетные формы никак не связаны с отчетными, крайне сложны и включают несущественные или непредсказуемые статьи

Последствия. Формы непонятны менеджерам, из-за чего возникают ошибки при планировании.

Как избежать? Максимально сблизить логику отчетов и бюджетных форм. Исключить из планирования несущественные и непредсказуемые статьи, закрепив соответствующие правила в методике план-фактного анализа.

Слишком длинный или короткий период бюджетирования

Последствия. Слишком длинный период приводит к нереалистичному бюджету. Слишком короткий – к сложности в оценке ресурсов и возможностей финансирования, а также планировании бизнес-проектов.

Как избежать? Период бюджетирования должен быть сопоставим с динамикой изменений внешней среды; позволять адекватно оценивать деятельность.

Слишком частый или слишком редкий пересмотр бюджета

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

Как избежать? Частота пересмотра бюджета зависит от целей бюджетирования. Если они – комплексные, целесообразно иметь две версии бюджета: одну для постановки целей (частота изменений определяется частотой изменений самих целей, структуры и деятельности компании) и вторую – для прогнозирования (частота изменений зависит от частоты существенных изменений внешней среды, компании, отклонений факта от плана).

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

Как избежать? О терминах необходимо договориться на начальном этапе бюджетирования. Целесообразно закрепить терминологию нормативно в форме методики. Полезным оказывается соответствующее обучение персонала. Особенно это необходимо сотрудникам, которые не относятся к ФЭС.

Неправильное выделение ЦФО

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

Как избежать? Выделение ЦФО должно осуществляться после утверждения оргструктуры компании. Необходимо определить, на основе каких критериев и до какого уровня управления будут выделяться ЦФО. Отнесение подразделений к типам ЦФО должно базироваться на целях, поставленных подразделениям, и уровне их ответственности.

Ошибки при автоматизации

Неадекватное использование Excel

Последствия. Реализация слишком сложной модели в Excel приводит как к чисто техническим трудностям (медленная работа, сбои), так и к недостоверности данных (отсутствуют встроенные механизмы согласования данных и ограничение доступа). Нет технической возможности ввести регламент.

Как избежать? Проектируя бюджетную модель в Excel, сразу закладывать механизмы выверок, чтобы можно было искать ошибки. До внедрения специализированного программного средства ограничивать сложность бюджетной модели, используя укрупненную аналитику статей и ограниченное число ЦФО.

Неправильный выбор момента автоматизации

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

Как избежать? На стадии планирования проекта внедрения бюджетирования определить момент принятия решения об автоматизации. Это должен быть отдельный этап, входящий в общий план постановки системы бюджетирования.

Ошибки организационные

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

Как избежать? Целесообразно внедрять системы комбинированного контроля – оперативного и по отклонениям. Необходимо выделить статьи, существенно влияющие на денежный поток, и включить их в контур оперативного контроля.

Контур контроля по отклонениям определяется целевыми показателями и влияющими на них факторами.

Непродуманный анализ отклонений

Последствия. Поспешное принятие решений, стремление достичь 100 % точности и реагировать на все изменения (мелкие/крупные), анализ только негативных отклонений, высокие трудозатраты.

Как избежать? Выделить существенное, исходя из показателей.

Ошибки при мотивации исполнения бюджета (возложение ответственности без полномочий; поиск виновных, а не причин отклонений; постановка завышенных/ заниженных показателей; частая смена показателей; недооценка натуральных показателей)

Последствия. Демотивация менеджеров. Недостижение целей.

Как избежать? Границы ответственности менеджеров должны быть «прозрачны», а целевые показатели – синхронизированы с объемом полномочий. Менеджерам необходимо принимать активное участие в согласовании и защите бюджетов. Степень жесткости показателей должна зависеть от степени «прозрачности» структуры компании: чем структура запутанней, тем более интегрированные показатели нужны.

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

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

Последствия. Если нет связи с целями более высокого уровня (стратегическими), эти цели не достигаются. Кроме того, не все процессы (например, строительные проекты) укладываются в год.

Как избежать? На стадии формирования стратегии надо сразу формировать долгосрочные цели и уточнять их на ближайший год в бюджетах. Взаимосвязь стратегического плана и бюджета обеспечивается через показатели. Создавая бюджет, следует ставить задачи в привязке к стратегическим целям. Так, неправильно брать цель: «Увеличить прибыль компании по отношению к прошлому году на 3 %». Почему именно 3 %? Правильнее выбирать цель, ориентируясь на стратегический план: если в стратегии запланирован 20 % рост прибыли на ближайшие пять лет, то стремление получить за ближайший год 3 % не позволит достичь долгосрочной цели – бюджет должен быть более напряженным.

Оперативное планирование платежей происходит в отрыве от бюджета. Или наоборот – целиком ориентировано на бюджет

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

Как избежать? Бюджет должен служить ориентиром для оперативного плана. Статьи, которые стабильны, могут полностью переноситься из бюджета. А статьи, которые значимы и подвержены существенным колебаниям, должны уточняться с определенной периодичностью; такой же, с какой составляется оперативный план. Снизить трудоемкость оперативного планирования позволяют резервы.

Благодарность за этот раздел Михаилу Булушеву («Автомир», «Снежная королева»)

3.3. Постановка оперативного учета

Я за то, чтобы учет длился мгновения, осуществлялся в режиме реального времени и не силами финансистов.

Е. Плаксенков, генеральный директор «МИЭЛЬ»

Проектирование бизнес-функций

Поиск и идентификация бизнес-функций (БФ) необходимы для определения объектов (что учитывать) и субъектов (кто будет учитывать) УУ.

Что такое бизнес-функции? В самом простом виде перечень БФ вашей компании совпадает с перечнем структурных подразделений. Например, бизнес-функция «Закупки» может на 100 % выполняться департаментом закупок, «Продажи» – отделом по работе с клиентами. Однако особо крупными и значимыми закупками может заниматься, например, лично генеральный директор. Если бы мы ограничились описанием субъектов УУ лишь с точки зрения организационной структуры, мы бы пропустили очень важного субъекта УУ – генерального директора и очень важный объект УУ – наиболее крупные закупки.

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

Взгляд на то, чем занимается ваша компания, под углом бизнес-функций полезен тем, что вы сможете переосмыслить, как именно работает ваш бизнес (см. пример в табл. 3.2).

Таблица 3.2. Сопоставление бизнес-функций и ЦФО

Модель предприятия в виде бизнес-функций может быть иерархической. Не рекомендуем увлекаться и расписывать модель более чем на два уровня. Помните – главной целью описания бизнес-функций является определение субъектов и объектов УУ (см. пример в табл. 3.3).

Таблица 3.3. Типовые бизнес-функции производственного предприятия

Проектирование бизнес-процессов

Что такое бизнес-процесс? «Бизнес-процесс – совокупность последовательно или/и параллельно выполняемых операций, преобразующая материальный или/и информационный потоки в соответствующие потоки с другими свойствами. БП протекает в соответствии с управляющими директивами, вырабатываемыми на основе целей деятельности. В ходе БП потребляются финансовые, энергетические, трудовые и материальные ресурсы и выполняются ограничения со стороны других БП и внешней среды. Частными случаями БП являются организационные, технологические и другие процессы» (ГОСТ Р 50.1.031-2001 «Терминологический словарь»).

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

Пять причин описания бизнес-процессов:

1. Они все равно существуют.

2. Определение порядка взаимодействия бизнес-функций.

3. Выявление недостатков процессов.

4. Получение наиболее полного перечня объектов УУ.

5. Выход на карту автоматизации.

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

Главная цель описания БП для постановки оперативного управленческого учета – регламентация ведения субъектами УУ учета объектов УУ. Такая цель накладывает естественное ограничение на детализацию описания БП и на степень «охвата» всех БП предприятия. У вас может существовать производственный БП контроля качества выпускаемой продукции. Но описать следует лишь ту часть, которая затрагивает регистрацию объемов готового продукта, прошедшего ОТК.

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

Существует отдельная категория БП предприятия, которую необязательно описывать в целях УУ. Это организационно-распорядительный документооборот (ОРД). Из всего процесса обработки входящей корреспонденции вас должна интересовать обработка присланных на ваш адрес счетов к оплате. А из огромного процесса составления договора с клиентами – лишь шаги, ведущие к регистрации основных учетных параметров договора (сумма, срок, данные контрагента, перечень продукции и т. п.).

Как описывать БП?

Существует множество методик описания бизнес-процессов, например SADT[13].

Недостатком SADT является то, что ее символика не очень удобна для чтения неподготовленного пользователя. Хотя те, кто едва научился разбираться в символах SADT, обычно сразу становятся адептами этой методологии. Мы рекомендуем использовать SADT как инструмент познания нового для вас бизнес-процесса или даже целой бизнес-функции. Она помогает улавливать суть исследуемых процессов, не пропустить ничего важного и избавиться от лишних деталей. Поэтому общую версию описываемых БП лучше всего представлять в понятном для всех табличном или даже текстовом (списочном) виде (табл. 3.4).

Таблица 3.4. Таблица бизнес-процессов

Есть еще один способ описания БФ и БП. По возможности всегда старайтесь не плодить документы – описывайте все изначально в компьютерной системе – той, где вы предполагаете вести управленческий учет.

Если ваша текущая система не соответствует требованиям УУ и вы собираетесь ее менять, необходимо как можно больше данных сохранять в электронном формате, легко переносимом из программы в программу. Как соотносятся между собой БФ и БП? На языке программистов отношение БФ к БП характеризуется как «один ко многим»: одна БФ охватывает несколько БП. Исключением из этого правила являются сквозные бизнес-процессы. Например, формирование бюджета доходов и расходов. Потому что сквозные БП пронизывают несколько БФ (см. рис. 3.1). То есть в области планирования мы с вами уже выполнили необходимые описания, в результате которых бизнес-функция «Управленческое планирование» была декомпозирована до БФ второго уровня «Бюджетное управление». Внутри этой функции мы обозначили бизнесс-процесс – регламент бюджетного планирования. Его итог – основные бюджетные формы (суть – объекты УУ). Центры финансовой ответственности, а также конкретные ответственные за формирование бюджетных форм лица (в виде должностей) являются субъектами управленческого учета.

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

Кстати, об ограничениях. Останавливаться в описании обычных бизнес-процессов на том или ином уровне нужно, когда вы понимаете полный перечень объектов и субъектов УУ. Чаще всего это второй или третий уровни. Если мы не можем найти верное ограничение, проект грозит утопить своих участников в мелочах.

В любом случае, пока вы не начали описывать БП, вы не можете понять, где следует остановиться. Не забывайте и о том, что необходимо описывать ТОЛЬКО то, что

связано с учетом как таковым. У всего проекта описания БП не должен быть заголовок типа «УУ в компании N (название вашей компании)». УУ – не цель, а средство их достижения. Каких именно целей? Если вы хотите вовремя знать себестоимость продукции, в первую очередь надо включить в перечень описываемых БП производственные, закупочные, логистические и т. п.

Однако в постановке целей (равно как и в следовании им) не стоит перебарщивать: у собственника может существовать «сиюминутная» цель, а внедрение УУ – рассматриваться как акт общекорпоративного оздоровления. Это опять же не означает, что УУ является самоцелью. Просто вам нужно будет подумать о том, какие еще цели, кроме оперативных, вы хотели бы и/или могли бы достичь с помощью внедрения УУ (см. пример типового перечня БП в табл. 3.5).

Таблица 3.5. Перечень бизнес-процессов одного производственного предприятия

Е. Плаксенков: «Исходить из целей учета – значит, идти по процессному пути. Он длиннее и извилистее. Знание процессов часто предоставляет выбор между двумя разными

дорогами. Управленческий учет – финансовое описание бизнес-процессов. Мало кому интересно при постановке управленческого учета описывать существующее. Но раз уж взялись за описание, надо что-то улучшить. Строительство правильного учета предполагает реинжиниринг бизнес-процессов, полное эталонное описание «как на самом деле все должно быть». Не буду рассказывать, к чему приводит реинжиниринг бизнес-процессов. Это тоже бесконечное занятие. К тому же никто не знает, как выглядят идеальные бизнес-процессы. Но я знаю, как должен выглядеть идеальный бизнес-результат. На языке финансов это – бюджетные отчеты, в которых план-факт отклонение показано согласно стандартам, выработанным человечеством за 500 лет. Сколько бы ты ни изобретал новое, в конечном итоге еще никто не придумал лучше «трех форм» бюджетного управления[14].

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

На практике, чтобы поставить и внедрить управленческий учет, многим компаниям достаточно описания БП. Равно как и наоборот: частенько для выявления всех субъектов и объектов учета можно пользоваться описанием исключительно БФ. Но, как известно, для осознанного выбора необходимо досконально изучить все предлагаемые варианты.

В заключение еще одна цитата из государственных стандартов: «Управление предприятием – это особый вид БП предприятия, в ходе которого определяются цели предприятия, собирается и анализируется информация о ходе производственных процессов, принимаются решения и выполняются действия, направленные на достижение целей» (ГОСТ Р 50.1.031-2001 «Терминологический словарь»).

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

Полученные в ходе описания БФ и БП объекты и субъекты являются основой для проектирования рабочих мест УУ (см. пример в табл. 3.6).

Таблица 3.6. Соотнесение БФ и БП для определения рабочих мест

С внедрением УУ у многих сотрудников появятся новые функции. Основные изменения, которые привносит оперативный учет:

• новые атрибуты документов;

• новые типы документов;

• новые места регистрации документов;

• новые требования ко времени регистрации документов.

Управленческий учет – целое море новой аналитики. Д. Новоселов: «Следующим шагом [после разработки финансовой структуры] было упорядочивание системы учета – план счетов и единый план счетов. Предприятия нам достались разные, исторически с неодинаковыми планами счетов. К моменту моего прихода у бухгалтеров не было задачи свести все воедино. Они закрывали потребности и готовили отчетность для фискальных органов, чтобы не переплачивать налоги. В то время у нас было три предприятия[15]. Каждое решало свои мелкие вопросы и все. Большой проект по внедрению единого плана счетов, созданию аналитик для управленческого учета – отдельная песня.

Пришлось бороться с бухгалтерами, для которых введение любой аналитики является дополнительной работой».

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

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

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

Б. Рябов: «Есть определенные процессы, где нет и не может быть никакого дублирования. Например, сбор первичных данных, он универсален. Так, сбор чеков в торговой организации – одинаковая операция для всех видов учета. Сбор данных по товародвижению идет с первичных систем; информация выбирается со складской или ERP-системы. Затем то, что мы требуем от финансовой отчетности, создает системы следующего уровня, а они, в свою очередь, могут проявлять собственные характерные черты. Появляются «вторые вводы», проверки и прочее. И все же первичные сведения по товародвижению собираются из базовых систем один раз. И даже у разных систем принцип один и тот же».

Новые места ввода первичной информации. Учетные события регистрируются в местах их возникновения либо, в крайнем случае, – в местах получения информации об их возникновении. В разделе 3.2.2.2 «Проектирование финансовой структуры» мы ввели термин «Центр финансовой ответственности». Сотрудники ЦФО отвечают не только за финансовый результат своего подразделения, но и за корректность информации, предоставляемой предприятием в целом. Следовательно, за своевременную и точную регистрацию учетных событий, возникающих в рамках деятельности ЦФО, должно отвечать данное ЦФО. В некоторых компаниях в качестве регистратора операций УУ выступает финансовый отдел или особая группа специалистов. Иногда это связано с физической невозможностью следовать правилу «регистрации операций в местах возникновения учетных событий». ЦФО «Буровая вышка №» не оборудовано компьютерной техникой и, следовательно, не может своевременно регистрировать учетные события. Хотя пока мы говорим про «бумажный» учет. Следовательно, отсутствие компьютера «на месте» не является причиной, по которой нельзя зарегистрировать то или иное учетное событие. Бумажные журналы никто не отменял и не забывал! Во всех иных случаях мы считаем нецелесообразным и противоречащим идее УУ организовывать ввод первичной информации в специализированных подразделениях.

Из всего вышесказанного можно сделать вывод, что в УУ распространена следующая схема регистрации учетного события:

1. Регистрация события с малой долей «документированности». УУ позволяет регистрировать учетное событие без 100 % наличия обязательных атрибутов операции. Например, отгрузка товара может осуществляться «безадресно»: на некий корабль грузится определенный товар, но его конечная цена, а также привязка к конкретному покупателю не зафиксированы. Вместе с тем, требования к УУ подразумевают максимально оперативный учет подобных отгрузок. В приведенном примере вы можете «отгрузить» товар по текущей средней или планово-нормативной цене (метод учета зависит от принятой политики УУ). Получателем может выступать «условный» клиент, наименование которого дает вам описание грузов, находящихся в пути.

2. Уточнение параметров события № 1, то есть регистрация более точных параметров вместо условных или регистрация события с точными данными при одновременном сторнировании «условного» события.

3. Регистрация события-преобразования (назовем его событие № 2), когда регистрируется, например, разгрузка корабля. Данное событие снабжается документами, подтверждающими факт отгрузки товара конкретным покупателям по определенным ценам и известной на данный момент себестоимостью.

Кое-что из перечисленных примеров легко реализовать с помощью традиционного бухгалтерского учета. Главное, чтобы все «условности», необходимые вам в УУ, были аккуратно прописаны в политике БУ и соответствовали законодательству. Но в таком случае цели УУ и БУ будут совпадать. А при совпадении целей нет нужды «держать» две бизнес-функции. Что и подтвердила на практике компания «Валента»: «У нас получается, что одни и те же люди – бухгалтеры – занимаются и бухгалтерским, и управленческим учетом. Я давным-давно принял для себя простую схему, которая объясняет, кто делает управленческий учет. Существуют три типа ведения управленческого и бухгалтерского учета:

I. Когда массивы данных не пересекаются.

II. Когда массивы данных пересекаются частично.

III. Когда массивы данных полностью совпадают либо лежат один внутри другого.

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

Для каждого типа нужна своя система ведения учета.

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

А что будет, когда бизнес начнет расти? В этом случае налицо – удвоение ресурсов: необходим оператор для управленческого учета и бухгалтер – по бухгалтерскому. Два человека со схожими функциями. Причем специалист по управленческому учету должен быть умнее. Ведь бухгалтер работает по законодательству, а его коллега должен понимать, что делает (как в ситуации с отечественным бухучетом и МСФО). Да еще знать английский, отечественные и международные стандарты, сравнивать их между собой.

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

Бухгалтер формирует реальность…

Неизвестный финансовый директор

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

Итак, уяснив для себя все предпосылки возникновения новых рабочих мест, можно приступать к составлению таблицы соответствия ролей и бизнес-функций:

Таблица 3.7. Соответствие ролей и функций

Колонка «Шаги бизнес-процессов» описывает должностные обязанности роли, связанные с УУ. Роль – это совокупность должностных обязанностей. Рабочее место – топографическое обозначение мест(а), где должны выполняться обязанности конкретной роли. В общем случае и роль, и рабочее место являются субъектами учета. Но пользователь – конкретный субъект учета, идентифицированный с помощью имени.

Соотношение Роль —* Рабочее место —* Пользователь описывается как «один ко многим».

Рабочие места УУ являются ключом к инструкциям рабочих мест. Что в них нужно описать? Обратные идентификаторы: наименование роли/рабочего места, наименование и код бизнес-функции. Инструкция разбивается на разделы, соответствующие шагам бизнес-процессов. В каждом описывается:

1. Типы обрабатываемых в рамках данного шага БП событий.

2. По каждому типу – инструкции, разъясняющие процедуру регистрации или генерации соответствующего учетного события.

Процедуры масштабирования

Ваша организация может измениться на любой стадии внедрения УУ. Поэтому нужно предусмотреть вероятные точки роста.

Экстенсивное развитие не предполагает изменения в перечне ролей и, как следствие, инструкций. Интенсивное развитие, связанное с прогрессивно-качественными изменениями, корректирует перечень ролей.

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

Конечно, нельзя описать все предполагаемые изменения в компании на много лет вперед. Горизонт прогнозирования изменений = срок внедрения + срок опытной эксплуатации системы УУ. Обычно, – от одного года до двух лет (зависит от масштаба предполагаемых изменений, связанных с УУ).

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

1. Какие БФ будут задействованы предполагаемым изменением?

2. Какие БП?

3. Повлекут ли эти изменения корректировки перечня БФ (появление новых БФ, удаление старых)?

4. Повлияют ли эти изменения на суть БП (изменение существующих БП, добавление новых, удаление старых)?

Ответив на перечисленные вопросы, вы сможете подготовить описания предполагаемых изменений в методологии УУ. В общем виде они будут включать переход к новой версии методологии УУ (см. главу 5 «Развитие УУ»).

Центр компетенции и методологии

Двигателем любого нового дела является команда. Вариантов ее названия – масса: «Центр компетенции», «Методологическая группа», «Отдел управленческого учета», наконец.

Цель создания такой группы:

1. Формализация целей внедрения УУ.

2. Разработка методологии УУ, включая все виды проектирования.

3. Координация работ по внедрению УУ.

4. Актуализация всех материалов по УУ (инструкции, политики, описания) в соответствии с организационными изменениями.

5. Контроль соответствия эффектов от внедрения УУ поставленным целям.

6. Обучение сотрудников организации методологии УУ.

Кто образует команду? Первоисточником изменений в направлении УУ на предприятии обычно является руководство. Если это генеральный директор, лучше ему не возглавлять ЦК. Такого инициатора во многих методологиях называют «спонсор». Главным в ЦК должен стать исполнительный менеджер. Так, в нашей практике разные фирмы часто передавали этот пост в руки финансового директора или его первого заместителя (потенциальный преемник). Бывали случаи, когда ЦК возглавлял директор по качеству. Членами ЦК могут быть сотрудники финансового департамента, бухгалтерии и любых других подразделений, так или иначе задействованных в процессе внедрения УУ. В идеале нужно отрядить по одному человеку из каждого ЦФО. Однако, вопреки расхожему мнению, в ЦК не должны входить их руководители. Ведь основной функцией ЦК является исполнение, а руководителям некогда составлять управленческий план счетов, описывать БФ и БП, формировать инструкции пользователей. В ЦК должны входить те, кого руководители ЦФО считают кадровым резервом, – любознательные люди, которым всегда интересно сделать нечто большее, чем определено их должностными инструкциями. Вообще участие в столь знаковом и глобальном для компании проекте, как внедрение УУ, является достаточно мощным карьерным рычагом. Впоследствии участники ЦК часто занимают те или иные руководящие посты. Это целеустремленные, в большинстве случаев – молодые и обладающие компьютерной грамотностью специалисты.

С психологической точки зрения называть такое организационное образование отделом не совсем правильно. Внедрение УУ – проект. Автоматизация УУ – другой проект. Назвав центр компетенции управленческого учета отделом, вы «цементируете» данное структурное образование на долгое время, лишая его мобильности.

Иногда встречается такая ошибка: руководство решает организовать УУ силами отдельно взятого (пусть даже специально для этого организованного) отдела. Подобное решение задачи, на первый взгляд, выглядит убедительно – появляется структурное подразделение, отвечающее за оперативную и достоверную регистрацию учетных событий в целях УУ. Их коллеги работают в прежнем режиме. Никакие революционные изменения казалось бы не требуются. Однако есть нюанс, который в 90 % случаев является решающим. Реализация УУ силами автономной группы людей размывает ответственность за итоговые цифры в управленческой отчетности. Не будет никакого делегирования полномочий, а значит, и качественного изменения компании.

Центр обработки данных

Задача центра обработки данных – регистрировать все учетные события вместо ответственных лиц, которые по тем или иным причинам не в состоянии этого сделать.

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

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

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

Зачастую для регистрации и обработки документов организуют специальную группу. Она может функционировать на базе финансового отдела или бухгалтерии либо быть выделенным подразделением.

Б. Рябов: «Наш общий центр обслуживания (Shared services centre) запускался в 2007–2008 годах. Идея системы такова. Не держать в 25 городах по два-три бухгалтера, а собрать их всех в регионе, где стоимость рабочей силы ниже московской, и проводить учетные операции там. При этом собирать «первичку» и взаимодействовать с налоговиками на местах, а операции по МСФО и сведение осуществлять централизованно в одном или нескольких местах».

Иногда УУ реализуется путем не регистрации, а переделки (перекладки) отчетности. Это необходимо, если мы имеем дело с минимальным уровнем УУ, цель которого – реклассификация существующей финансовой отчетности в управленческих целях.

Пример. В целях УУ необходимо «отступить» от принятой политики бухгалтерского учета и отобразить себестоимость товарных запасов, исходя из их рыночной стоимости. Или, например, руководство предприятия желает видеть суммы сделок на более ранней, нежели заключение договора, стадии.

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

Дополнительные сведения к постановке оперативного учета

Почему необходимо описывать бизнес-процессы?

1. Они дают понимание бизнеса.

2. Они подсказывают, как необходимо изменить бизнес.

3. Они обеспечивают коллективную работу над изменениями.

4. БП распределяют ответственность и, тем самым, гарантируют контроль и корректность выполнения.

Если не сходятся контрольные цифры или не выдерживаются сроки предоставления отчетности, виноваты процессы. Либо не оптимальны сами процессы, либо люди, ответственные за их выполнение (нарушают взятые на себя обязательства).

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

Виды учетных событий

С точки зрения природы учетного события, мы можем выделить плановые и фактические учетные события.

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

1. Производственный план-график фиксирует прогнозируемые учетные события – выработка продукции.

2. Годовой бюджет отдела продаж фиксирует прогнозируемые учетные события – объемы реализации продукции.

3. Отчет «Анализ рыночных рисков» фиксирует прогнозируемое учетное событие – взлет цен на международном рынке на основное сырье завода.

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

Пример. Приказ о создании нового подразделения непосредственно влияет на учет (как минимум, изменяется финансовая структура). Приказ о выходных и праздничных днях опосредованно влияет на УУ, но все-таки больше относится к сфере управления человеческими ресурсами.

С точки зрения причины возникновения события можно разделить их на два типа – регистрация и генерация.

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

Генерация внутреннего документа. Счета заказчикам. Платежные поручения (вы платите). Подвид – генерация внутреннего отчета.

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

4. Технологическая поддержка управленческого учета

4.1. Введение в комплексные системы класса ERP

На сегодняшний день автоматизация управленческого учета прочно ассоциируется с компьютерными приложениями класса ERP (Enterprise Resource Planning – планирование ресурсов предприятия). Это очень мощные, функционально богатые продукты, охватывающие практически весь спектр деятельности типового современного предприятия. Вот минимальный перечень подсистем (первый уровень списка) и модулей (второй уровень) типовой ERP-системы:

1. Финансы:

1) Работа с главной книгой.

2) Расчеты с заказчиками.

3) Расчеты с поставщиками.

4) Кассовые и банковские операции.

2. Логистика:

1) Отгрузки.

2) Поставки.

3) Запасы.

4) Дистрибьюторы.

5) Цепочки поставок.

3. CRM:

1) Продажи.

2) Обслуживание клиентов.

3) Маркетинг.

4. Производство:

1) Производственные мощности.

2) Планирование.

3) Производственные заказы.

4) Цеховое управление.

5. Кадры:

1) Кадры.

2) Зарплата.

3) Карьера.

4) Обучение и развитие персонала.

Каждый модуль содержит как минимум три основные группы функций:

1. Справочники.

2. Формы ввода.

3. Отчеты.

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

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

Разработка справочников. Несколько советов

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

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

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

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

Если говорить об автоматизации процесса ввода информации в справочники, лучше воспользоваться системой, которая обеспечивает помощь в создании справочников. Самый простой принцип – электронное анкетирование. Вы входите в систему и выбираете позицию «Завести новый товар». При этом не попадаете сразу в карточку товара с десятком полей (рис. 4.1). Предварительно система просит вас охарактеризовать его:

– Речь идет о материальном активе или нет? – спрашивает система.

– Материальный актив, – выбираете вы.

– Это основное средство или малоценное и быстроизнашивающееся?

– Малоценное.

Рис. 4.1. Ввод информации в справочник

Идеальная система не просто верит вашим ответам, но еще и перепроверяет: «Какова стоимость этого предмета?» И если вы ответите, что она превышает, например, 10 000 руб., система вас поправит – в этом случае предмет будет относиться к основным средствам.

Системы, построенные по принципу «вопрос-ответ», часто называют экспертными. Ими пользуются телефонные службы медицинской помощи «911», их применяют для технической диагностики самолетов и прочих технически сложных устройств. Главная цель таких компьютерных программ – систематизировать знания о сложных объектах или способах реагирования на те или иные ситуации и помочь человеку быстро, а главное – безошибочно сориентироваться в этих знаниях. Преимущество использования такого подхода в ERP-системах очевидно. Во-первых, вы можете сразу вносить свои классификации и корректировать их по мере ввода. Во-вторых, отвечая на вопросы, вы себя перепроверяете (правильно ли выстраивается аналитика?). Кроме того, весь комплекс сценариев «вопрос-ответ» пригодится в будущем тем, кто станет заводить новые товары.

И все же в вопросно-ответной системе без достаточного объема информации легко запутаться. Есть старый проверенный механизм классификации путем «маскирования»: справочник делится на сегменты; каждый сегмент соответствует определенному аналитическому признаку; заводя элемент, вы выбираете из возможных вариантов.

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

Заведение новой товарной единицы

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

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

Первичные признаки, которые необходимы для создания новой товарной позиции, лежат в области товароведения. Первым вопрос решает товаровед. Он классифицирует товары по основным группам и передает их для детальной классификации категорийному менеджеру. Разные группы товаров ведут разные менеджеры: один хорошо разбирается в алкоголе, другой – в продуктах быстрого питания и т. д. Карточка нового товара «ходит» по цепочке ответственных и постепенно дополняется. Недопустима ситуация, когда товар заводится в момент его прибытия на склад: как брать на баланс то, что не ожидали получить? Если товар прибыл на склад, значит, его предварительно заказали. Следовательно, и классифицировать его надо как минимум на стадии заказа. Проблем возникнуть не должно. Если товар заказали, значит, у предприятия есть соответствующий вид деятельности. Если есть вид деятельности, значит, он фигурировал в бизнес-плане, и под него были заведены плановые статьи дохода, то есть продумана финансовая классификация изделия.

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

При формировании справочника возникает вопрос: как классифицировать – как есть или как должно быть?

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

Например, ИТ-компания планирует бизнес-деятельность в области телекоммуникаций. Естественно, она не может предсказать наверняка, с какими видами затрат столкнется, какие потери закладывать. Идеальное решение – приобрести уже существующий справочник какой-нибудь телекоммуникационной компании. Практически для каждой отрасли можно найти типовые справочники. Покупка будет не очень дорогой и крайне полезной. Не всегда стоит изобретать велосипед – порой достаточно сформулировать свои требования и попытаться найти нужный справочник.

Основные справочники

Основные справочники группируются по тем же категориям, что и функции ERP-системы.

1. Финансовый справочник учетных регистров, включая управленческую аналитику

Любому предприятию нужно разработать учетный классификатор – план счетов. Это некое дерево, которое подразумевает сами учетные регистры, аналитику и т. д. Иногда на практике к статьям затрат и статьям доходов относятся как к разным справочникам. В действительности они и есть разные. Но в системах они размещены в одной сущности под названием «План счетов». Группы активов – тоже, казалось бы, отдельная сущность. Однако и она находится в плане счетов. Правильнее формировать справочники из нескольких субсправочников («доходы-расходы», «виды услуг – виды продукции» и т. п.). Во-первых, это экономит место на диске. Во-вторых, помогает связать друг с другом статьи затрат и статьи доходов. Понятийно это один справочник, но пользоваться им будут разные люди, и система должна обеспечивать уровень безопасности, при котором пользователи видят только те элементы справочников, доступ к которым им разрешен. Сотруднику, работающему с доходами, совсем необязателен доступ к статьям затрат. Более того, на некоторых предприятиях (например, оборонного комплекса) это может быть сугубо конфиденциальная информация. Также исключение лишней информации устраняет вероятность ошибки ввода.

2. Логистика. Справочник товаров и услуг

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

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

Экспертная система позволяет параллельно вести несколько справочников. При заведении аналитики по товарным группам для финансиста и для кладовщика система должна напоминать, что вы ввели новую классификацию для финансиста и ей не соответствует ни один элемент в справочнике кладовщика.

Некоторые фирмы в качестве справочников используют финансовую структуру. Дублирующим ее справочником является структура организационная. В стандартных системах это один справочник с альтернативными иерархиями (см. понятие «Альтернативная иерархия» в главе «Управленческое планирование»).

3. CRM[16]. Справочник ваших контрагентов

Существуют разные мнения по поводу того, следует ли держать всех контрагентов в одном справочнике. Это зависит от типа бизнеса. Например, в идеологии CRM есть классификация: b2b, b2c. Если вы работаете по второму принципу (приобретаете у юридических лиц, а продаете конкретным физическим лицам), собирать всех заказчиков и поставщиков в одном справочнике смысла нет. Это совершенно разные объекты учета, разные элементы аналитики, даже разные карточки учета. Более того, принцип b2c, например, для сотовой компании подразумевает справочник заказчиков с разной степенью детализации для разных систем или подсистем. Для целей планирования и учета трафика не нужно знать каждое конкретное лицо, которое приобретает сим-карту. Достаточно группировки по количеству абонентов на регион. Кто эти абоненты, неважно. А сотрудникам, которые выставляют счета (зачастую в отдельной системе – биллинговой), надо учитывать каждого абонента, фиксировать всю историю взаимоотношений с ним. Да, мы говорим об одном справочнике, но с точки зрения детализации и целей использования они очень разные.

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

4. Производство

В производстве базовым справочником является Bill of materials, связывающий материалы друг с другом в комплекты. Bill of materials во многих системах называется спецификация изделия, в других – комплект, в третьих – отдельно учитываются узлы. Формирование такого справочника – задача не из легких, потому что изделия бывают альтернативными. Например, при сборе стульев используется определенная категория дерева, но для каких-то соединительных деталей сорт дерева непринципиален. При отсутствии необходимой древесины система должна сама предложить альтернативный вариант. В нее вводится понятие «альтернативное изделие», которое позволяет более гибко подходить к производству в условиях разветвленной классификации. «Потерявшись» в аналитике, сотрудник может не найти необходимый материал. Система страхует от подобных случаев, предлагая близкий вариант в другой группе.

Такие ситуации могут сорвать планирование. При планировании производства (например, через несколько месяцев произвести определенное количество компьютеров) система должна через справочник спецификации изделий сформировать план наличия этих изделий на складе и план поставки комплектующих. Здесь тоже пригодится технология альтернативных изделий. Если этого понятия в системе нет, она выдаст результат: по истечении такого-то срока предприятие сможет собрать лишь 20 компьютеров, хотя планировалось 40. При анализе причин выясняется, что на складе отсутствует необходимая модель вентиляторов. А на самом деле вместо этих вентиляторов можно брать другие.

Производственная специфика дает понимание, насколько важно заранее продумать структуру справочника.

5. Кадры

При формировании базового справочника нужно учитывать, что грамотная кадровая система включает работу не только с существующим, но и с будущим (равно как и с бывшим!) персоналом. С точки зрения целесообразности, эти категории лучше развести по разным справочникам, потому что режим работы с сотрудником и не работающим в компании человеком – разный; частота обращений к таким записям тоже неодинаковая.

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

Итог по работе со справочниками: разработка справочников – это отдельный проект.

Ввод данных

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

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

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

Еще один немаловажный момент – удобная форма ввода и дружественный интерфейс. Часто пользователей отпугивает громоздкость форм. Каждый хочет видеть лишь те поля, которые он использует. Поэтому на рынке востребованы не сами системы, а их деривативы – отраслевые решения. На мой взгляд, оптимальное решение – использовать все многообразие функций крупной системы, но настроенной под конкретную отрасль. Например, решение для торговли. Основные категории товаров разработаны и введены в систему. На всех формах ввода фигурируют поля, которые следует заполнять именно работнику торговли. Даже названия полей могут быть адаптированы под конкретную отрасль. Многие компании, специализирующиеся на доработке известных систем до уровня «отраслевое решение», идут еще дальше – выпускают решения для конкретного типа предприятий (супермаркетов, бутиков, магазинов класса DIY и т. п.).

Компания Intentia – разработчик ERP-систем для конкретных отраслей. Если, например, Oracle выпускает бизнес-приложение, а партнеры создают на его базе отраслевые решения, то Intentia изначально выпускает разные системы для конкретных отраслей. Есть Intentia for electricity, Intentia for process industry. Причем итоговый продукт – это не голая система, куда необходимо вводить все справочники, а система с преднастроенными справочниками. Из них достаточно убрать лишнее. И все! Судя по финансовым показателям и динамике роста Intentia, можно говорить о востребованности таких решений на рынке и серьезной отраслевой сегментации систем. Еще одно преимущество отраслевых решений – экономия времени и денег на внедрение, потому что многое не придется создавать с нуля.

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

Извечный вопрос: кто под кого должен подстраиваться – клиент под систему или система под клиента? Отвечать на него следует в индивидуальном порядке. Значительную экономию денег и времени при внедрении системы обеспечивает подход «подстраивания» под систему: она диктует, каким должен быть бизнес. Но здесь есть подводные камни. Любой бизнес уникален. Так, бизнес компании British Petroleum в каждой отдельной стране не похож на другой. Если количество уникальных моментов превалирует или есть один, но самый критичный, правильнее перенастроить систему. Например, вы производите эксклюзивный продукт с помощью соответствующего, эксклюзивного персонала. Вы зависите от каждого такого сотрудника. Если ему не хочется меняться, и вы не можете на него повлиять или кем-то заменить, придется под него подстраивать систему. Надо понимать: сможете ли вы так замотивировать персонал, чтобы он изменил стиль своей работы. Дело даже не в саботаже, хотя часто приходится сталкиваться именно с этим. Такова природа человека – мы не любим новое.

Поэтому при внедрении системы важно учитывать человеческий фактор – насколько люди готовы к переменам. В быстроразвивающихся отраслях, вроде ритейла, телекоммуникаций, услуг, работают динамичные и гибкие люди. Они обычно легко переходят на типовое решение. В промышленности (металлургия, машиностроение и т. п.) все строится на традициях. Из производителей автомобилей лишь Toyota меняет эти представления, а остальным присуща преемственность поколений. Чем больше династий, тем сплоченней коллектив, и это приводит к скептическому отношению к переменам.

Обнаружив в форме непонятные поля, сотрудники настораживаются. Особенно те, кто занимались исключительно бумажным учетом и никогда не задумывались о страховом запасе, минимально пополняемом запасе, точке дозаказа и т. п. Однако эти поля были созданы для «всех возможных» отраслей или являются настроечными. Избежать их невозможно – таковы требования автоматизации процессов. Это лишь маленький пример, в каждой форме таких нюансов может быть масса. Нормальная система позволяет ликвидировать сложности: если поле не используется, пользователь, наделенный соответствующими правами, делает его невидимым. После «косметического» изменения оставшиеся в форме поля эргономически распределяются по странице, ликвидируя «дырки». Таким образом, структура меню (последовательность подсистем и модулей) настраивается под конкретного пользователя. Пользовательские настройки лучше производить, создавая роли, о которых мы говорили в разделе 3.3 «Постановка оперативного учета».

Одна или несколько

В среде ИТ-специалистов это вопрос из разряда «философских»: вам нужна одна общая система или несколько разных? В мире преобладают две тенденции: комплексность (укрупнение) и сервисность.

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

Есть у комплексной системы и свои недостатки. В частности, ее сложно дезинтегрировать. Ну, нет у вас сейчас потребности (желания, денег, времени) внедрять модуль «отгрузки», вполне хватает «производства» и «логистики». А система без этого модуля работать не может. В «урезанном» варианте при списании готовой продукции со склада невозможно пользоваться стандартными функциями отгрузки – комплексная система потребует указать номер заказа, код заказчика и т. п. Приходится брать на вооружение функцию фиктивного списания товарных единиц со склада, которая обычно используется для корректировки остатков (в том числе при инвентаризации). После того как вы обучите пользователей такому списанию, вам придется их переучивать, когда решите внедрить модуль «отгрузки». Это еще один маленький пример. Интегрированные крупные системы недаром так называют: они настолько крупные, что попытка дезинтеграции оборачивается серьезными дополнительными тратами. Принцип комплексной системы – сделать все сразу в одном учетном кольце. Нужно заранее обдумать, как внедряемый модуль будет отражаться в финансах, потому что впоследствии перенастроить финансовую часть логистики и производства не удастся. По этой же причине сначала формируются классификаторы, а потом следует внедрение.

Вторая идеология – сервисная – предусматривает, что конкретную задачу выполняет отдельная программа. И пусть у каждой из них есть свои справочники – они должны хорошо взаимодействовать, чтобы однотипные данные систем не противоречили друг другу. Плюс сервисного подхода – результативность. Например, вы автоматизируете работу с заказчиками (точечная автоматизация) и внедряете соответствующий модуль, не дожидаясь синхронизации с кладовщиками. У них – другая система. Минус этого подхода в том, что трудно отследить единую версию данных. Системы должны хорошо интегрироваться одна в другую. Если возникнет недоверие к отчетности одной из систем, придется проверять все остальные – две, три, а то и все 10, где могла зародиться ошибка. В разработке сервисных систем есть такое понятие – единое хранилище данных, – куда каждая система отсылает сформированные показатели. Здесь же находится единое хранилище справочников. И не может быть несколько равнозначных справочников по одному и тому же предмету.

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

Отчет

Мы выделяем три вида отчетности: динамическая, статическая и интерактивная.

Выбор в пользу статических отчетов предопределяет привычка и специфика бизнеса. Статическая отчетность предназначена для распечатки и генерируется в заведомо неизменяемом формате. Например, PDF или специальном формате системы. Хотя многие системы позволяют делать баланс предприятия в виде таблицы Excel, эта универсальность может навредить: в таком формате легко внести изменения. Конечно, аналитик, формируя отчет, не будет трогать баланс. Но если отчет создает сама система (например, ежедневно генерируется отчет о производственных остатках), его нужно защитить, чтобы сохранить достоверность представленных руководству цифр.

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

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

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

О. Урнев: «Если бухгалтерская отчетность подчиняется определенным законам, которые мы обязаны не нарушать, то управленческая отчетность – это воля руководителя, что мы будем отслеживать, что отражать в отчетах и для чего. Главное требование управленческой отчетности, в отличие от бухгалтерской, – не форма и не способ визирования или предоставления, а удобство восприятия. Управленческая отчетность, которую сложно усвоить за нескольких минут, становится бесполезной. Она должна обладать двумя признаками – оперативностью и удобством для восприятия.

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

Всего по производству отслеживается 12 показателей. Я беру только производительность по агрегатам, причем не на всех участках, а лишь на самых болезненных – учет складских показателей и показателей по персоналу.

Ежедневно я смотрю отчеты производства продукции за смену и за сутки, отслеживая работу агрегатов, которые для данного сортамента работают на полную мощность, без запаса. Это узкие места, определяющие производительность всей линии. Спустя месяцы мы можем решить вопросы по этим агрегатам и не будем отслеживать их работу. Почему мы не уделяем внимание другим точкам? Не потому, что они менее важны. Просто всего не охватишь, а управленческая энергия конечна, надо расставлять приоритеты. Остальные места контролируются, но с меньшей периодичностью. Если я не буду отслеживать работу этих агрегатов, вероятно, важность данного отчета для остальных директоров будет потеряна. К тому же я сам должен быть в курсе происходящего. Чтобы, увидев отчет о выполненной за сутки работе, не задумываться – много это или мало. Мне, как руководителю, необходима качественная оценка, а не констатация факта. В производстве дать качественную оценку проще, чем в финансовой деятельности, стратегическом планировании, при работе с персоналом. Ведь управление персоналом – достаточно инертный механизм: сегодня ты снизил затраты на обеспечение, а завтра потеряешь работников.

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

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

Б. Рябов: «Причины запуска единой транзакционной системы таковы. В компании все было достаточно фрагментировано: разные системы в разных регионах. Помню, выбирали, какую систему ставить. И московская была не лучшей – так исторически сложилось. В 2004–2005 годах все проанализировали и решили взять уфимскую систему, более приспособленную ко всем процессам. Нашим первым приобретением стала самая удачная информационная система.

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

Чтобы сказать – товар такого-то производителя реализован у нас за неделю в таких-то объемах по всей стране, – нужно было проделать большую и кропотливую работу. Потому что для сбора всех данных нужно держать их в одной системе либо иметь несколько правильно состыкованных систем. Для финансового учета знание о том, что именно мы покупаем, не так важно.

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

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

Мы пытались делать по-другому – собирать информацию в единое хранилище данных из разных систем. Но сложность все равно была высока. Допустим, вчера мы купили сеть и хотим, чтобы сегодня была информация о продажах в разрезе НАШИХ товарных категорий. Это зависит от интерфейса, программного обеспечения сети и понимания того, по какой логике устроены ее процессы. На понимание может уйти несколько месяцев: отсутствует нужная аналитика и нужно организовывать дополнительный ввод. Тем не менее, получать актуальную информацию о новой сети необходимо. Тогда оптимальное тактическое решение, которое возникало в этой ситуации, выглядело так: пусть финансовый контролер этой сети по телефону раз в день сообщает о продажах в разрезе торговых точек. В офисе внесут эти цифры, и будет табличка хотя бы по базовым показателям. Это необходимо, потому что информация требуется оперативно. При тиражировании нашей системы во вновь приобретенную сеть мы получим нужные цифры в нормальном расширенном виде. Но поскольку решения принимаются здесь и сейчас, следует понимать, что происходит с оперативным управлением. Такую информацию приходится дополнительно дозапрашивать».

Ликбез по многомерным базам данных

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

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

В качестве ликбеза расскажу о реляционных и многомерных базах данных. Реляционные – это привычные столбцы и строки. Такая база позволяет аккуратно и компактно хранить документы. Сначала зародился именно такой тип баз данных. Но впоследствии встал вопрос: как интерпретировать полученные сведения? Для получения отчета приходится сводить множество таблиц: отчет в разрезе по продавцам – в одной, по регионам – в другой, отгрузки – в третей, категории – в четвертой. А в следующий момент времени понадобится новый набор таблиц. Процесс увязывания реляционных таблиц растянут во времени. К тому же на предприятии формированием отчетов занимаются сотни людей, и на систему ложится огромная нагрузка. А при современной динамике бизнеса цифры изменяются постоянно. Пока вы формируете отчетность из различных показателей, они успевают измениться. Поэтому переход к многомерному подходу стал логичным. Многомерное хранение данных подразумевает множество измерений. Цель многомерности – в любой момент любые данные можно сопоставить друг с другом. Правда, это приводит к избыточности: некоторые данные не сочетаются; никому никогда не придет в голову их связать. В таких хранилищах нет операций – лишь итоговые результаты, только метаданные[17]. Отсюда возникло чисто физическое противоречие: чтобы иметь такие отчеты, необходимо перекачивать данные из реляционных таблиц в многомерные. При любом режиме эксплуатации, комплексном или сервисном подходе, у вас будет две версии правды – в реляционном и многомерном виде.

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

До недавнего времени многомерные системы характеризовались тем, что через них можно было только смотреть данные. Но любой аналитик хочет вводить информацию, например, чтобы проводить сценарный анализ «что будет, если…»: что произойдет, если будут такие затраты и такой уровень налогов? Многие системы названного класса предусматривают подобные опции прогнозирования. Однако человечество шагнуло еще дальше и пришло к осознанию, что бюджетирование лучше делать в многомерных системах. Бюджетируя, мы анализируем и, анализируя, бюджетируем. Создавая бюджет с нуля, приходится обыгрывать различные версии: бюджет не статичен при создании и во время получения фактических данных. Сравнивая план с фактом за первый квартал, вы корректируете план на следующий квартал в зависимости от результатов.

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

Мы выделили данные, которые должны быть в ERP-системе, но, как говорилось ранее, это всего 30 % данных, которые создаются на современном предприятии. Есть еще приказы, распоряжения, протоколы, тексты договоров. Где хранить их – вопрос уже не к управленческому учету, а к системе документооборота.

4.2. Классификация систем обеспечения УУ

Чтобы помочь вам разобраться с существующими на рынке бизнес-приложениями, мы разработали таблицу.

Таблица 4.1. Категории бизнес-приложений

В строках этой таблицы перечислены основные задачи информационного обеспечения практически любого предприятия. Функциональное наполнение каждой остается «за кадром»; подразумеваются стандартные функции той или иной области менеджмента. Например, задача «Маркетинг» в фирме, занимающейся продажей рекламы, довольно сильно отличается от маркетинга компании – дистрибьютора импортного врачебного оборудования. И, тем не менее, обе найдут в стандартном маркетинговом наборе ERP-системы следующие функции:

• Маркетинговые кампании и акции.

• Рассылки.

• Обработка лидов и т. п.

Как видно из таблицы, практически для каждой задачи существует несколько отдельных (stand alone) систем. Это доказывает теоретическую возможность автоматизации любой функции вашего предприятия отдельными мини-системами (сервисами).

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

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

Без инструментов business intelligence не обойтись в сферах, где вращаются большие объемы данных:

– потребительские товары;

– розничная торговля;

– финансовые услуги;

– транспортные услуги.

Последний обзор Accenture выявил, что из 162 опрашиваемых CIO 40 % уже используют BI для поиска конкурентоспособной ниши; 76 % будут инвестировать в BI и в хранилища данных в ближайшие месяцы; 57 % рассматривают BI как основной компонент для конкурирующих преимуществ в ближайшем будущем.

CPM – по определению Gartner Group подразумевает использование методов и средств BI совместно с методологиями, процессами и метриками для управления эффективностью бизнеса (performance). При этом принципиальное значение имеют два обстоятельства: ориентация CPM-систем на применение различными сотрудниками компании и мощная интеграционная составляющая, заложенная в архитектуру и функциональность CPM-приложений. В практическом плане концепцию CPM можно определить как интеграция и автоматизация процессов мониторинга систем сбалансированных показателей, аналитических приложений и средств бизнес-планирования.

ERP-система – Enterprise Resource Planning System – система планирования ресурсов предприятия, корпоративная информационная система (КИС), предназначенная для автоматизации учета и управления. Как правило, ERP-системы строятся по модульному принципу и охватывают ключевые процессы деятельности компании, интегрируя все ее подразделения в единую систему. Главный «ингредиент» любой ERP-системы – унифицированная база данных, хранилище всех сведений и показателей из различных системных модулей.

Термин ERP, по сути, не соответствует своему определению. Забудьте о планировании (Planning), ERP-системы для этого не предназначены. И о ресурсах (Resource) тоже забудьте – термин не дает ясного представления о том, что именно учитывает система. Но запомните часть, касающуюся предприятия (Enterprise) – в нем сущность ERP-системы. Исторически ее концепция стала развитием стандартов MRP (material requirement planning – планирование материальных потребностей) и MRP II (manufacturing resource planning – планирование производственных ресурсов). Важно отметить, что это были именно общепринятые стандарты. Второй термин отличался от первого включением производства: в этот стандарт вписывались расчеты производственных ресурсов и их загрузка для корректного распределения материалов.

Потом на свет появился термин ERP. Базировавшийся на стандартах MRP и MRP II, но сам не являвшийся стандартом, он породил неразбериху в толковании. Разные компании-поставщики называют предлагаемые продукты ERP-системами. Начинается разночтение. Что должно входить в ERP? Попадает ли сюда управление персоналом? Вроде, это часть управления предприятием, но точного стандарта нет. Поэтому неясно, можно ли систему без модуля по управлению персоналом считать ERP. По мнению многих, в понятие ERP входит функционал MRP и MRP II плюс обработка финансов, кредиторка/дебиторка, денежные потоки.

SCM – supply chain management, управление цепочками поставок – это процесс планирования, внедрения и контроля операций цепочки поставок. Управление охватывает все движение и хранение товаров и незавершенной продукции от момента ее возникновения до момента потребления.

Управление цепочками поставок включает:

– снабжение;

– закупку;

– перемещение;

– логистику;

– взаимодействие с партнерами, поставщиками, посредниками, сторонними организациями, оказывающими услуги, и покупателями.

WMS – warehouse management system – система управления, обеспечивающая комплексную автоматизацию управления складскими процессами. Она является ключевой составляющей цепочки поставок и контролирует движение, хранение товаров на складах, а также отвечает за получение, транспортировку, раскладку и сортировку товаров.

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

Тут перечислены не все категории систем. Мы не указывали те из них, которые решают узкие вопросы. И, тем не менее, системы, которые подразумеваются в третьей колонке, могут быть совершенными и выполнять свои функции гораздо лучше, чем, например, система класса ERP.

Важное замечание в адрес ERP: здесь имеется в виду «классический» набор функций систем, которые принято называть ERP.

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

• Компания SAP (Германия) производит продукт ERP-класса SAP R/3 и систему управленческого планирования и анализа SAP SEM.

• Компания Oracle (США) производит продукт ERP-класса Oracle e-Business Suite и систему управленческого планирования и анализа Oracle EPB (Hyperion).

Обращаем внимание, что приведенная здесь классификация является актуальной на момент написания данной главы книги (середина 2009 года). Поскольку ИТ-мир изменяется весьма стремительно, выбирая систему, стоит прислушаться к мнению независимых аналитиков, таких как Gartner, AMR Research, IDC, чтобы получить новейшую классификацию систем. Хотя, конечно, основополагающие принципы еще долго будут оставаться неизменным. С ними вы можете познакомиться в следующем разделе.

4.3. Подходы к выбору программного приложения

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

Разрабатывать или внедрять готовое

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

СОЗДАТЬ ИЛИ КУПИТЬ?

У организаций есть две возможности для работы с программным обеспечением CPM: создать собственное или купить готовый пакет. Чтобы сделать правильный выбор, надо знать все плюсы и минусы каждого варианта.

СОЗДАНИЕ ПРОГРАММНОГО РЕШЕНИЯ CPM

Внедрение решения влечет за собой выбор технологической платформы и создание всех компонентов, необходимых для CPM. Кто-то должен создать модель предприятия; написать программы и процедуры для расчета делового регламента; разработать пользовательский интерфейс, с помощью которого будут контролироваться различные CPM-процессы; описать порядок формирования отчетных и аналитических форм. Чтобы внедрить такое решение, организации могут совместить стандартные промышленные технологии (например, электронные таблицы для отчетности) с базой данных OLAP (оперативная аналитическая обработка данных), которая используется для построения модели.

ЗА: Выгоды от создания собственного CPM-решения:

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

– Разработка решения контролируется самой организацией. Она определяет порядок и уровень функциональности на выходе.

ПРОТИВ: Причины, по которым фирма должна серьезно подумать, нужно ли ей создавать собственную CPM-систему:

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

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

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

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

– Организация будет вынуждена самостоятельно производить бета-тестирование – это придется часто делать в производственной среде.

ПОКУПКА ПРОГРАММНОГО РЕШЕНИЯ

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

ЗА: При условии, что правильно выбран поставщик (есть рекомендации компаний, которым он успешно предоставлял CPM-решения), выгоды от использования данного подхода будут следующие:

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

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

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

– Бета-тестирование системы произведено другими компаниями. Она работает и может быть предоставлена оперативно. Благодаря опыту предшественников успех внедрения и использования можно оценить до начала дорогостоящего процесса внедрения.

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

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

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

ПРОТИВ: Несмотря на то, что есть причины предпочесть покупке CPM-системы ее создание, тщательный выбор поставщика и системы может свести на нет эти проблемы:

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

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

– Первоначальные затраты слишком очевидны и могут затруднить получение одобрения руководства на старт проекта.

– Если поставщик неправильно понимает потребности организации, система может работать не так, как предполагалось, или (в некоторых случаях) не работать вовсе.

– Продукт может оказаться ненадежным, службы технической поддержки – неквалифицированными. Это сделает решение нежизнеспособным.

– Поставщик может прекратить использование продукта или даже выйти из бизнеса. Тогда программа лишится технической поддержки и придется снова тратить деньги – на внедрение нового продукта.

Из-за сложности и широты CPM-решений большинство CPM-пакетов предлагают открытый подход. То есть программное обеспечение имеет встроенную функциональность, которая расположена на поверхности основной базы данных. Это дает организациям дополнительные возможности. Необходимо, чтобы выбранный поставщик подтвердил оказание технической поддержки в случае корректировки системы. Если такого подтверждения нет, выбранное решение превратится в самое худшее из всех возможных: все «против» без гарантий хотя бы одного пункта «за». Другая опасность – выбор пакета, который в соответствии с маркетинговыми материалами поддерживает CPM, но изначально не был предназначен для этой цели. Такой подход также объединит в себе «против» как возможности создания системы, так и возможности ее покупки, и отдельные «за» – и все это за высокую цену.

Большая или маленькая

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

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

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

• производственные предприятия (одно или несколько);

• сервисные предприятия;

• обслуживающие производственные предприятия в области ремонта;

• поддержания чистоты территории;

• коммуникаций и т. д.

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

«Тяжелая» или «легкая»

Размер вашей компании сильно влияет на круг систем, из которых вы будете выбирать. Системы делятся на «легкие» и «тяжелые» (см. табл. 4.2). «Тяжелые» – это не негативный, а классификационный признак комплексной, многофункциональной и постоянно «растущей» системы. В их «арсенале» появляются новые функции, специфичные для конкретных отраслей; особенно если речь идет о стремительно развивающихся во всем мире отраслях (ритейл, телеком, сервисные отрасли). «Легкие» системы обладают основным функционалом, ориентированным в основном на финансовый и бухгалтерский учет. В них типы производственных учетов и управления ограничены. Если компания представляет собой несколько разнопрофильных суббизнесов, в каждом из которых есть персонал, работающий с будущей системой управленческого учета (в пределах нескольких десятков пользователей), возможно, стоит выбрать для них «легкую» систему. Самым главным признаком «легкости» является то, что «легкие» системы не станут «тяжелыми». То есть если вы покупаете «легкую» систему на предприятие, растущее от 50 % в год – по обороту, документообороту, количеству персонала и учетных событий, – она со временем может не выдержать объема регистрируемых данных.

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

Таблица 4.2. Рекомендации по выбору «размера» системы

Момент выбора категории системы – чуть ли не самый важный. От него зависит инвестиционная составляющая. Выбрав «тяжелую» систему, вы обрекаете себя на большие затраты по ее покупке, дорогостоящее (миллионы долларов) и длительное (от одного до трех лет) внедрение. В случае с «легкими» системами в пересчете на одно небольшое предприятие речь идет об инвестициях порядка 200–300 000 долларов за типовой набор функций: финансы, снабжение, сбыт, производство, логистика. На их внедрение уйдет от шести месяцев до одного года.

В табл. 4.2 приведены ориентиры для выбора системы. Главная метка – количество одновременно работающих с системой пользователей. Также необходимо учитывать объем обрабатываемых документов. Например, компания является депозитарным центром. При небольшом количестве пользователей (20–30, казалось бы, «легкая» система потянет) ей приходится обрабатывать большие массивы данных (несколько десятков тысяч документов в месяц). В таком случае руководство должно принять решение о внедрении отнюдь не «легкой» системы.

В таблице упомянуты и «средние» системы. Яркими представителями данного класса являются Microsoft Dynamics NAV и AX. Средние сроки их внедрения – от шести до 18 месяцев с общим бюджетом 500-1 500 000 евро. В ряде случаев внедрение средней системы по бюджету может быть сопоставимо с внедрением «тяжелой». Обычно такое происходит в очень крупных холдингах, решивших устанавливать не единую централизованную систему, а нескольких систем среднего размера в каждом подразделении.

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

Комплексная или сервисы

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

Как определить, является ли интересующая вас система популярной, распространенной и востребованной? Кроме прямых признаков – известность, представительство в стране, положительные отзывы прессы, – есть один косвенный: компания, поставляющая бизнес-приложение, сама не должна заниматься внедрением. Для этих целей существует широкая сеть партнеров, консалтинговых компаний и системных интеграторов. Но для развития своего продукта компании-поставщику необходимо иметь в своем арсенале экспертов. Их разработки будут опережать потребности клиентов на два шага вперед. И совсем неплохо заручиться поддержкой таких людей. То есть договор о внедрении вы будете заключать с консалтинговой компанией, а контроль его качества может осуществлять разработчик. Это, конечно, дополнительные расходы, но они часто окупаются. Неудачное же внедрение и отсутствие единой системы контроля может привести к ситуации, когда вы не знаете, кому предъявить претензии. Если это – плохо настроенная программа, вроде, виновны консультанты, а за недоработанный функционал системы, по сути, ответственность лежит на поставщике. Чтобы не гадать, нужен единый контроль качества разработчика. По крайней мере, он гарантирует надлежащее исполнение партнером всех процедур и правил по настройке установленной у вас системы.

С чего начинать выбор

Распространенный вопрос: с чего начать выбор? Многие успешные компании сначала определяются с системой и только потом – с партнером по внедрению.

Ни в коем случае не полагайтесь исключительно на мнение компании о конкурентах – оно может оказаться необъективными.

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

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

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

Если системный интегратор внедряет системы обоих классов, неплохо уточнить, какое у них соотношение в общем объеме бизнеса. Самые известные производители «тяжеловесных» систем – SAP (продукт «SAP/R3») и Oracle (продукт «Oracle E-Business Suite»). Есть системы и для среднего бизнеса – «Microsoft Dynamics AX» и «Microsoft Dynamics NAV» от Microsoft, «SAP Business One» от SAP и «Oracle JD Edwards» от Oracle. Бесспорным лидером для оптимизации малых и средних предприятий является «1С» и фирмы, которые занимаются ее внедрениями (их больше тысячи).

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

Вторая волна – выбор внутри класса. Ни в коем случае не сравнивайте «легкую» систему с «тяжелой» – она будет уступать почти по всем параметрам. А в итоге проиграют обе.

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

Важное замечание. Некоторые системы честно или нет могут оказаться одновременно в обих сегментах. Что значит «честно»? Есть предприятия, где количество работающего в системе персонала превышает 100 человек или вообще измеряется сотнями, и система (допустим, Microsoft Dynamics NAV, бывший Navision) справляется с такой нагрузкой. Раз она может работать с сотней пользователей, несколько десятков ей ни по чем. Это называется честный перехлест. А нечестный – это когда поставщик-разработчик «насильственно» позиционирует продукт несоответствующего вашим потребностям размера. Например, если поставщик «тяжелой» системы сильно демпингует, чтобы выполнить квартальный план. Это плохо для вас, потому что как бы мало вы ни заплатили за лицензии, впоследствии вам придется платить за сопровождение превосходящей ваши реальные масштабы системы и за работу консультантов по высоким ставкам. Вообще во всем IT-мире затраты на внедрение системы в разы превышают суммы на ее приобретение. Другой случай – производитель малой системы утверждает, что его система запросто сможет работать с большими объемами данных и внушительным количеством пользователей. Такую информацию нужно просто проверять. Фирмы, использующие эти системы, на себе испытали все тяготы внедрения. Если вы найдете по каждому из рассматриваемых вендоров, минимум, двух счастливых клиентов, значит, и вендор говорит правду, и система вам подходит.

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

Конечно, выбираемое бизнес-приложение должно быть совместимо с той операционной системой, которую вы используете на всех компьютерах. Не сегодняшний день самой распространенной ОС является Windows. Хотя, возможно, вы используете открытые технологии, например, один из деривативов системы класса Linux. Надо четко понимать: система не должна привести к тотальным изменениям, а, значит, – дополнительным и порой крупным инвестициям в IT-инфраструктуру, которая уже имеется и эксплуатируется.

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

Контрольный пример

Окончательный выбор мы рекомендуем делать в режиме тендера. Так вы сможете сопоставить множество необходимых вам системных требований. Но! Очень важно, чтобы основные функциональные потребители будущей системы (например, линейные руководители подразделений, чья деятельность будет автоматизироваться) оценили функциональность систем-претендентов. Чтобы детальный «просмотр» оказался продуктивным, и у вашей рабочей группы была возможность сопоставлять более-менее одинаковые факторы, необходимо разработать контрольный пример. В нем описывается (см. Пример программы и методики испытаний на CD) один из сквозных бизнес-процессов вашей компании или его упрощенный прообраз. Следует прописать даже минимальный набор классификаторов и цифровые значения регистрируемых документов. Таким образом консультанты будут вынуждены «преднастроить» свои системы для показа вам. Все это делается, чтобы по ходу презентации системы они четко следовали разработанному в примере сценарию. Кроме того, вы сможете видеть «свои» данные, а не цифры и названия товарных единиц отвлеченного типового примера.

Запасной план

Говоря о волнах, мы подразумеваем некую промежуточную фазу и возможность возврата к более раннему этапу. Что имеется в виду? Вы выбрали сегмент – необходима «тяжелая» система. Из имеющихся на рынке отобрали лучшую. Затем следует второй этап – выбор партнеров. Система должна быть хороша не только потому, что она функциональна, представлена в России и локализована (есть много примеров удачных внедрений и счастливых клиентов), но и потому, что в следующей фазе, когда вы станете выбирать консультантов, у вас будет широкий выбор. Или их будет немного, но все они – успешны, и все их внедрения заканчивались положительно. Данный критерий необходимо выявить еще на первой волне. Переходя к решению вопроса с консультантами, не стоит сжигать все мосты. Вы можете остановиться на двух системах, удовлетворяющих вашим критериям, либо выбрать одну основную и вторую «запасную». На этапе выбора интегратора вы можете столкнуться с тем, что ни один консультант не в силах гарантировать качественное внедрение вашей системы-лидера. Тогда задействуется план Б, и вы анализируете итоги работы консультантов, внедряющих «запасную» систему. О том, как выбрать поставщика услуг по внедрению системы управленческого учета, мы расскажем в следующем разделе.

ВЫБОР СИСТЕМЫ

Секреты покупки информационной системы[18]

Как не купить слона в мешке и распознать типичные уловки недобросовестных sales-менеджеров?

Кейс: Как клиент выбирает ERP-систему? Всегда ли задает те вопросы, которые действительно важны? Что чаще всего упускают из вида при общении с консультантами, рассмотрении коммерческих предложений?

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

1. Вы покупаете именно тот результат, который вам нужен.

2. В полном объеме.

3. В обещанные сроки и надлежащего качества.

4. Сравниваете сопоставимые по уровню и качеству продукты/услуги.

В процессе переговоров многие вопросы по разным причинам не проговариваются, а додумываются: например, когда клиент интересуется стоимостью проекта, на этот вопрос редко услышишь конкретный ответ. О стоимости проекта говорится только в связи со ставками занятых в нем консультантов. Или другой пример. Заказчик хочет понять, насколько быстро в системе можно доработать тот или иной функционал. Вместо часто задаваемого пространного вопроса о «гибкости» лучше конкретизировать: сколько времени требуется на разработку одного отчета в данной ERP-системе? В ответ могут последовать сравнимые показатели – час, день или неделя. Очевидно, что чем меньше времени тратится на разработку отчета, тем выше «гибкость» системы. Иногда чересчур ловкие продавцы пользуются невнимательностью клиента. Например, такому продавцу стал известен бюджет клиента на проект или предложение конкурирующей фирмы. Что может сделать недобросовестный продавец для предоставления более выгодных, на первый взгляд, коммерческих условий? Допустим, в коммерческом предложении на проект ограничить объем разработок тремястами человеко-часами. Если уловку не заметят, проект может просто не дойти до стадии опытной эксплуатации: 300 рабочих часов закончатся, а готовой системы еще не будет, и клиенту выставят счет за дополнительную работу программистов. Что выходит? Клиент ожидает получить систему «под ключ» по фиксированной цене, а вместо этого имеет 300 часов работы программиста. Почувствуйте разницу… Иногда продавцы уговаривают клиента подписать договор о работах первой стадии, результатом которой является выработка технического задания (ТЗ). Это еще одна уловка: ТЗ компания пишет для себя, под ту систему, которую интегратор предлагает клиенту.

ТЗ, созданное одной компанией, не может быть потом реализовано другой без проведения дополнительных согласований. Таким образом, клиент вынужден продолжать работать с тем, кто создал ТЗ – ведь он уже вложил деньги в его разработку! Для клиентов важно, чтобы все прайс-листы на оборудование и программное обеспечение были составлены по одной и той же системе: в одной валюте, с одинаковым подходом к НДС (везде включен или не включен). Также заказчик должен быть уверен, что сделанное ему предложение включает все коммерческие (транспортные, командировочные и т. п.) расходы.

Еще один важный момент связан с внедрением систем, стадией опытной эксплуатации. Минимальный срок опытной эксплуатации крупной системы – полтора месяца, оптимальный – два с половиной. Для полной уверенности проследите, чтобы в ТЗ была указана ее продолжительность (не менее двух с половиной месяцев).

Кейс: Если ERP-системы сопоставимы, их надо по какому-то принципу оценивать. Трудно сказать, у кого из брендов – лидеров первой пятерки системы сильнее. У каждого есть свои преимущества, пути развития и способы привлечения клиента…

КОРУС Консалтинг: ЗАРи Oracle – сопоставимые системы, но со своими нюансами.

Кейс: Что будет определять выбор из двух сопоставимых по классу систем? Ясно, что не бренд, а конкретные плюсы, имеющиеся у каждой системы, которые подходят клиенту. Давайте подробнее остановимся на ситуации, когда клиенту нужно выбрать одно из нескольких конкурирующих предложений.

КОРУС Консалтинг: Здесь мы бы говорили не о брендах, а собственно о продуктах, самой компании-вендоре и о внедренце – как они развиваются, на что тратят деньги, как думают о будущем. На самом деле правильный выбор во многом определяет состав конкурсантов. Важно сравнивать продукты одного уровня. Это касается и выбора компании-консультанта. Почему стоимость импортных систем существенно отличается друг от друга? Все системы условно делят на четыре класса: тяжелые, средние, коробочные и… самописные. Делят по объему стандартного функционала и производительности. Например, есть такой критерий, как поддержка процессного типа производства (планирование, расчет затрат) – это обеспечивают не все системы. Критерием также может быть количество пользователей, которые одновременно могут работать в системе: только часть современных IT-решений может обеспечить одновременную работу в системе нескольких тысяч пользователей. Западные аналитики (Gartner, IDC) написали множество отчетов для обоснования, почему одна система «более ERP», чем другая. Однако изучение отчетов занимает много времени. Тем более, что практически у каждого вендора есть отчет, из которого следует, что именно его продукт – самый лучший. Как в такой ситуации определить, к какой категории относится продукт? Самый простой способ, как ни странно, – спросить о продукте у его конкурентов. Если не хотите спрашивать, можно воспользоваться другим способом. Этот вариант основывается на утверждении, что рынок (другие покупатели ERP) до вас уже сегментировали ERP-системы на классы. Результатом такого сегментирования является… стоимость. Утверждение спорное, но на практике работает. Уточните стоимость одного рабочего места в системе. В тех случаях, когда производитель отдельно лицензирует пользователей и функционал, запросите информацию о средней стоимость рабочего места. После этого вы легко сможете распределить ERP-системы по нескольким сегментам. Теперь можно сравнивать, особо не беспокоясь, что выбор идет между системами разных классов. Еще можно сформулировать детальные (до операций в системе) функциональные требования к ERP-системе. Попросить вендора отметить, что можно отнести к стандартным опциям, что – к нестандартным, а что – к «требует доработок». Полученную таблицу, при желании, можно прикрепить к договору. И если какой-то функционал до этого был стандартным, а в техническом задании стоит, что он «требует доработок», возникает вопрос. Но это субъективно, а цена в прайс-листе объективна: здесь рабочее место стоит столько, а здесь – столько; это разные классы систем. По аналогии с автомобилями: производители машин придумали их классификацию для того, чтобы потребители сравнивали сравнимые вещи. Представим, что клиент хочет оценить один и тот же проект с использованием сопоставимых ERP-систем. Получил два предложения: в одном стоимость – 100 000 у. е., во втором – 200 000 у. е. Сроки исполнения проекта совпадают. Где же «собака зарыта»? Есть несколько вариантов:

1. Вы сравниваете консалтинговые компании с разным уровнем рентабельности или квалификации. Чтобы это понять, запросите ставки (стоимость одного человеко-часа) и сравните со средними ставками по рынку компаний, специализирующихся на данной ERP-системе.

2. Консалтинговые компании сравнивают разные проекты. Составьте документ с требованиями к объему автоматизируемого функционала и списку ваших компаний (подразделений), которые будут вовлечены в проект. Предоставьте возможность всем конкурсантам сравнивать одинаковые требования.

3. Вы покупаете результат разной степени готовности (вспомним про случай с ограничением объема доработок системы). Уточните у конкурсантов, что будет являться результатом проекта и в каких случаях стоимость проекта может увеличиться.

4. Вам «продают» разное количество ресурсов. Запросите трудоемкость проекта (например, в человеко-днях) при условии 100 % занятости. Чудес не бывает. Если на проект по одинаковому продукту (или равных по сложности системах) вам ангажируют в два раза меньше ресурсов, чем в аналогичных предложениях, есть повод задуматься. Скорее всего «недостающих» консультантов или программистов вам предложат использовать за счет внутренних ресурсов компании.

5. Накладные расходы. Конечно, они редко составляют 100 % разницы (если только ваш проект не на Дальнем Востоке), но все равно уточните, входят ли они в стоимость.

Для оценки ставок и трудоемкости проекта клиент может составить сравнительную таблицу выполнения работ разными консультантами: просчитывается работа каждого сотрудника на проекте. Получаем общую человеко-часовую загрузку по всем стадиям проекта – N. Поделив итоговую стоимость на загрузку, получаем среднюю ставку, соотносим с ранее озвученными ставками на встречах и делаем выводы. Если ставки совпадают, консультанты честны. Фирма, которая нацелена на выстраивание долгих отношений с клиентом, готова доходчиво объяснить, из чего складывается стоимость проекта: вот эта цифра у нас в оферте не равна итоговой стоимости проекта потому, что не все моменты могут быть учтены на предварительной стадии. Она может быть увеличена или уменьшена на основании реального хода проекта. Расчет стоимости проекта по fixed-price, с одной стороны, позволяет в большей степени учитывать риски, но он и приводит к удорожанию в среднем на 20 %. Клиентам, у которых нет опыта внедрения систем и обученной команды, лучше запрашивать стоимость, рассчитанную по fixed-price, но помнить, что они при этом переплачивают за соответствующие риски внедренцев. Кроме того, клиентам можно посоветовать с самого начала работать с компанией-консультантом по следующему правилу: вы должны видеть менеджера проекта и консультантов, которых нанимаете. Требуйте участия в переговорах тех людей, которые будут потом работать на проекте со стороны исполнителя. Чтобы склонить вас к выбору именно этого партнера по внедрению, вам выделят лучшие кадры. Но зачастую проект реализуют не те люди, которых вам представили как будущих участников проекта.

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

Еще такой момент: нужно постараться объективно отнестись к рекомендациям клиентов. Если клиент говорит: «У нас все было хорошо, проект шел гладко, и сейчас у нас тоже все отлично» – это повод задуматься, потому что идеальных внедрений не бывает. Всегда есть шероховатости. Если клиент говорит: «У нас сейчас все нормально, но на этапе запуска была определенная проблема, с которой компания-консультант благополучно справилась», – такой рекомендации веришь.

Кейс: Бывает, что на один проект привлекаются различные подрядчики, выполняющие отдельно взятые работы. Как в этом случае минимизировать риски?

Мы, например, предлагаем и услуги по внедрению, и само оборудование. По большому счету, клиент, привлекая нас как генерального подрядчика, минимизирует риски. Договор заключается между нами и клиентом; никаких отношений с субподрядчиками он не имеет; ответственность за их работу несем мы. Советуем клиенту при переговорах придерживаться такой линии: «Я плачу вам за генподряд, что увеличивает стоимость работ, например, на 10 %. Вам решать, кого из подрядчиков нанимать. В любом случае вы отвечаете за весь проект».

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

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

Если вспомнить классику отечественной сатиры, ситуация – как в известной миниатюре Аркадия Райкина про пиджак. «К пуговицам претензии есть? – Вроде, нет. А проблемы есть».

Клиент должен настаивать на одном менеджере-кураторе обоих проектов, который и будет отвечать за результат работы всей компании. Еще хотелось бы поговорить о роли вендоров в проектах. Наиболее часто встречаются три типовые схемы взаимодействия с вендорами: когда их консультанты участвуют в проекте на субподряде, когда сам вендор выступает генподрядчиком или когда консультанты вендора подключаются на последней стадии проекта, приезжая и проверяя уже установленное оборудование, осуществляя контроль качества. Бывает, что клиент сам напрямую привлекает вендора к проекту ради скидки. В таком случае советуем это делать до выбора основного партнера – консалтинговой компании. Тогда клиент может разделить риски и ответственность за проект с вендором.

Кейс: Проектную команду, составленную из специалистов консалтинговой фирмы и заказчика, часто называют одним из условий успешности проекта. Но это одновременно и риски – если нечетко определены зоны ответственности и лицо, которое несет за проект конечную ответственность. Что можно посоветовать клиентам по этому поводу?

КОРУС Консалтинг: Проект, как правило, является совместной работой единой команды со стороны заказчика и со стороны исполнителя. Случается, исполнитель берется делать все сам. Но это трудный вариант. С самого начала нужно проговорить, кто какие работы и на каждой стадии проекта делает, за какие результаты отвечает. Кстати, это очень редко фиксируется, тем более на стадии коммерческих предложений…

…поэтому опытные клиенты просят прислать им не коммерческое предложение, а договор, а лучше бы и то, и другое с приложениями к нему, в которых четко расписано, что делает на каждом этапе представитель заказчика и за что он несет ответственность.

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

Кейс: Для серьезного бизнеса, тем более для публичного, ценность ERP-системы еще и в том, что она не зависит от консалтинговой компании, которая ее поддерживает. Мировые бренды остаются в моде. Как же клиенту противостоять магии бренда?

КОРУС Консалтинг: А зачем противостоять? Мы говорим, что для публичной компании ERP-система от транснационального вендора – это гарантия прозрачности и стабильности. В таких организациях из-за ухода отдельного человека (или отдела), поддерживающего систему, работа не остановится. Еще важный момент возникает при проверке отчетностей аудиторами: им гораздо легче это делать, когда они имеют дело со знакомой системой учета.

Правда в том, что надежная система от известного вендора снижает риски. Собственный программист может уволиться. Что в этом случае делать с самописной системой, которую он разрабатывал и поддерживал? Маленькая компания-разработчик может закрыться или перепрофилироваться.

На наш взгляд, магия брендов еще не достигла своего апогея. Она с каждым годом будет все больше. Логика выбора клиента зачастую такова: «Да, вы – классная компания, у вас классный продукт, но как вы называетесь? АСУ «Склад» версия 1.1? Мы вам верим, но есть решение Х от мирового лидера Y». Надежность, известность бренда много значит и для тех компаний, которые внедряют эти решения. При выборе между небольшой компанией, при всем ее потенциале и преимуществах, предпочтение отдается тем, у кого больше опыта и больше выполненных проектов. Клиенты говорят: «Мы выбираем их. Да, это дороже, но надежнее».

До недавнего времени было модно все выстраивать в одной системе. Самой главной приманкой для клиентов было: «Что у вас за зоопарк систем? В бухгалтерии одна, в логистике – другая. Проблема при интеграции, данные пропадают. Огромный ИТ-отдел. Короче, вам нужна единая система, одна база данных, где все интегрировано». То есть если систему нужно было расширять, то за счет соответствующих модулей от того же вендора, а не специализированного решения. Мне кажется, сегодня эта мода уходит. Кругозор клиентов расширяется. Становится понятно, что иногда правильнее предпочесть стратегию best-of-breed (лучшие системы в своем классе) стратегии единой системы. Всегда понятно, что в специализированном решении больше нюансов. Например, клиенту, внедряющему систему Oracle для основных операций в области розничной торговли, для операций на распределительном центре мы предложили Manhattan WMS – лучший на данный момент продукт в своей области в мире. При этом мы честно предупредили клиента, что он понесет дополнительные траты на интеграцию двух систем. Принцип нашей компании – всегда иметь в арсенале лучший продукт, как Manhattan в WMS, но вместе с тем предлагать клиентам весь спектр решений для его конкретной задачи, чтобы была возможность выбора. При этом будет ли система называться SAP, Oracle или Axapta, не имеет большого значения. Гораздо важнее, насколько она хорошо внедрена, а также какие результаты реально достигнуты в ходе проекта. Многие компании задумываются о повышении капитализации и готовятся к выходу на публичный рынок. Например, есть миф, что внедренный в компании SAP повышает капитализацию. Он идет от того, что заложенные в систему шаблоны бизнес-процессов понятны западным менеджерам.

Кейс: Консалтинговая компания, долго работающая на рынке, имеет как положительный, так и отрицательный опыт. Нужно ли скрывать информацию о своих неудачных проектах?

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

У нас уже второй или третий клиент просит устроить референс-визит как к успешному, так и к проблемному клиенту. Еще не один не ушел после данного этапа без заключенного договора на внедрение.

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

Кейс: Мне однажды задали очень резкий вопрос по поводу одного из наших ранних проектов, который многие непосвященные считают неудачным. Звонивший был уверен, что ничего объективного не услышит. Я ответила, что да, был проблемный проект, но давно; с тех пор у нас многое изменилось: накоплен опыт работы с такими проблемами, в этой же отрасли реализованы такие-то и такие-то успешные проекты и т. п. Постепенно разговор перешел в конструктивное русло.

КОРУС Консалтинг: Клиенты сегодня хотят понимать, что кроется за конкретным брендом. Ну и что, что Oracle или SAP – известны? Что мы от этого получим, какие реальные плюсы и возможные минусы? Клиенты становятся более профессиональными и в управлении ИТ-проектами. Появляется спрос на такие услуги, как предпроектное обследование, формализация бизнес-процессов и требований к информационной системе, бизнес-консалтинг.

Иногда требования к проекту (системе, качеству услуг) формирует «независимая» компания.

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

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

4.4. Выбор поставщика услуг по внедрению приложения

Д. Новоселов: «Систему оперативного учета мы внедряли собственными силами. Беда такого внедрения в том, что задачи выстраиваются постепенно и последние могут полностью или частично противоречить более ранним. Прелесть же любого консалтингового проекта состоит в том, что сначала пишется техническое задание, где согласовываются все нестыковки, а потом начинается само внедрение. У нас возникла проблема, когда на двух заводах внедрили одно и то же бизнес-приложение, но, по сути, – две разные системы. Это мешало получать объективные данные для управленческого учета. То дебиторку с кредиторкой на одном контрагенте не свести, то еще что-нибудь. Даже в рамках одного завода. Конечно, часть вопросов сегодня решены, но не все. Этот груз – сэкономленных денег на внедрении учетной системы – мы тащим за собой не первый год».

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

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

Итак, список претендентов на внедрение системы управленческого учета выглядит следующим образом:

1. Рекомендации коллег по цеху.

2. Интернет-публикации.

3. Рекомендации вендора.

Полезный совет может дать и ваш аудитор или управленческий консультант, которые помогали поставить управленческий учет. К их рекомендациям стоит прислушаться. Ведь если партнерство интегратора и управленческого консультанта давнее, между ними, скорее всего, есть взаимопонимание рабочих групп; они разрабатывают понятные друг другу документы. А вы выигрываете от их совместной работы.

Большой, но дорогой

Есть несколько коротких советов по выбору консультанта-интегратора, которые мы просто приводим списком:

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

2. Высшее руководство фирмы-интегратора должно быть вовлечено в проект и знакомо с руководством вашей компании еще до подписания контракта.

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

4. В команду по внедрению должен входить системный архитектор, обладающий опытом работы именно с вашим приложением. При сложных комплексных внедрениях менеджер проекта не должен совмещать в себе должность архитектора.

5. Каждый вендор присваивает своим партнерам различные статусы, подтверждающие их успехи при реализации и внедрении соответствующих систем. Чем выше статус рассматриваемого вами интегратора, тем больше шансов получить качественное внедрение.

6. Наличие сертифицированной системы управления качеством выполняемых услуг сегодня стало стандартом отрасли ИТ-интеграции.

7. Желательно, чтобы менеджер вашего будущего проекта имел действующий сертификат профессионального сообщества менеджеров проектов (например, PMI[19]).

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

9. Если вам необходимо послепроектное сопровождение, интегратор должен иметь выделенную службу поддержки, работающую с выбранным вами бизнес-приложением.

10. Методология внедрения интегратора должна быть не только сертифицирована в соответствии с международными стандартами (например, ISO 9001:2000), но и соответствовать методологии вендора.

Конфиденциальность

Многие боятся, что приход консультанта на предприятие приведет к раскрытию ноу-хау. Если, например, вы занимаетесь строительством, то консультант, работающий со строительными компаниями, может неким образом распространить ваши бизнес-процессы, уникальные и разработанные вами классификаторы (скажем, статей затрат и доходов) на других своих клиентов. Речь идет даже не о недобросовестности – с первых шагов консультанта на предприятии вы должны подписать с ним договор о конфиденциальности. Просто невозможно сделать более-менее оправданное, мотивированное и качественное коммерческое предложение, не узнав о вашем предприятии как можно больше. Чтобы застраховать себя от распространения извне вашей внутренней информации, следует оформить соглашение о конфиденциальности.

Тяжело перекрыть доступ консультантов к настроечным данным – справочникам, типам, коэффициентам, отчетным формам и т. п. Но закрыть для них документы и промышленные сведения можно. Делать это нужно перед началом опытной эксплуатации (см. раздел 4.6 «Методология внедрения»). Это вполне укладывается в суть передачи системы: вы эксплуатируете систему, которая принадлежит вам. Свободный доступ к ней должен быть лишь у вас, чтобы не размывать ответственность за то, что с системой происходит, между вами и консультантом.

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

Е. Плаксенков: «Я не уверен, что найдутся люди, которые смогут, даже получив полное описание проекта, в достаточно короткие сроки воспроизвести у себя то же самое. МСФО известны всем профессионалам. Стандарты PMI доступны каждому. Планы счетов написаны не иероглифами. Кодификаторы очевидны для тех, кто управляет процессами. Но на все нужно время и мозги. А люди всегда «перетекают» между компаниями: сегодня работают у консультантов, завтра – в девелоперском бизнесе и консультируют уже по другому направлению и в другой компании. Все полученные знания они уносят с собой. Поэтому конфиденциальность нематериальных активов условна. Это знание, которое живет своей жизнью. Я не хочу тратить время на раздумья: «Кто у нас это украл?». Важно двигаться вперед».

Интерес консультанта

Многие, конечно, могут спросить: «А причем тут интерес?» Это вещь не юридическая. Все, что нам нужно прописать в контракте, мы пропишем и будем требовать с исполнителя результат. (Мы касаемся, пожалуй, самой больной темы при автоматизации управленческого учета.) К сожалению, на стадии составления контракта максимально полно прогнозировать и результат, и инвестиции, а зачастую – и сроки невозможно. Случай с недобросовестным исполнением сторонами своих обязанностей в расчет не берем.

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

Конечно, это не приговор. Никто не говорит, что когда приходится платить больше за ремонт в конце (хотя вы плотно занимались ремонтом и контролировали процесс, высказывали пожелания, меняли их и радовались, а ремонтная бригада быстро все выполняла), вы не рады дополнительным инвестициям. Но вы их делаете осознанно, понимая, за что платите. Увы, это – реальность, ее не избежать.

Пилотные проекты

Тупиковым является вариант, когда вам предлагают так называемый пилотный проект, результатом которого становится техническое задание. Казалось бы, идея – красивая: вы страхуетесь от недобросовестно изготовленной системы и от недобросовестного консультанта; получаете техническое задание, которое потом можно предъявить другому консультанту, чтобы он внедрил другую систему. Все замечательно, но в жизни так не бывает. Любой консультант все равно делает техническое задание, если и не ориентированное на конкретную систему или хотя бы класс, то обязательно соответствующее его собственным стандартам и форматам. В большинстве случаев при смене консультанта новый обязательно попросит изменить ТЗ. Я уже не говорю о том, что потребуется новое обследование, интервьюирование ваших специалистов и т. д. То есть сценарий «проект, ТЗ, потом – все остальное» увеличивает стоимость проекта в целом.

В этом и предыдущих разделах мы намеренно подробно не рассматриваем вопрос составления так называемых опросников или контрольных листов. Примеры тендерных опросников по системам и по выбору поставщика услуг приведены в приложениях на CD.

Референтный визит

Лучший способ проверить качество поставщика услуг – позвонить нескольким его клиентам. Желательно тем, кто использует предлагаемое им решение давно. Правда, с тех пор, как они начали пользоваться системой, изменились ее версии да и сам бизнес клиента. Тем не менее, если вы услышите абсолютно восторженный ответ, он должен вызвать подозрения. Идеально, если он будет приправлен ложечками дегтя. «У нас были проблемы на стадии создания технического задания, но консультант убедил нас, что мы не должны менять цели внедрения по ходу проекта. Он пошел нам на встречу и сумел гибко подстроиться к предложенным нами изменениям. Благодаря этому мы получили проект в срок и надлежащего качества», – это объективный ответ, который вполне можно расценить как положительную референцию.

Если вы слышите отрицательный отзыв, надо по возможности разобраться в его причинах. Часто бывает, что виноват сам клиент. Возьмем самый простой случай – у компании меняется спонсор, двигатель, менеджер проекта. Любой проект – это воля какого-то человека. Даже если она выражена в нескольких словах, должен появиться некто, кто скажет: «Я отвечаю за вложение этих миллионов долларов в повышение эффективности нашей компании». Что происходит, когда такой человек уходит? Даже если миллионы потрачены не впустую и все работает, приходит новый сотрудник. Ему необходимы новые достижения и принижение успехов предшественника. В таких случаях компания, используя внедренную систему, может не дать положительных референций о ней и о консультантах. Поэтому ваша задача – выяснить реальную обстановку. Эмоциональная составляющая важна, но по большей части в начале разговора: «Довольны ли вы работой консультанта? Устраивает ли система?» и дальше вы углубляетесь в конкретику:

• Используют ли они эту систему?

• Кто использует? Сколько всего пользователей?

• Сколько человек поддерживает систему внутри компании?

• Какие еще системы используются на предприятии?

• Как долго длился проект? Совпал ли срок его внедрения с планом?

• Были ли отклонения в бюджете?

• Вы подстраивали БП под систему или наоборот? И т. п.

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

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

У заказчика необходимо спросить о целях проекта и насколько они были достигнуты. Здесь следует избегать ловушки: согласно статистике цели по мере внедрения меняются. Поэтому уточните, не корректировались ли цели. Расспросите референтного клиента, как они выбирали систему, поделитесь с ними своими предположениями и планами дальнейших действий. Можно взять перечень разделов, которые есть в этой главе, и задать вопрос по каждому из них:

• Как удалось выбрать систему?

• По каким критериям выбрали для себя поставщика?

• Что являлось «пилотным» проектом?

• Были ли проблемы на стадии тестирования?

• Как шла подготовка к проекту?

• Как формировалась рабочая группа проекта?

• Как люди мотивировались?

• Как они составляли устав, оценивали результаты и эффективность?

Короче говоря, вы можете задать руководителям референтной компании вопросы по каждому разделу данной книги: «А делали ли вы это? А как вы это делали?»

Команда

Ваши вопросы во время референтного визита могут конкретизироваться вплоть до фамилий конкретных консультантов. Они пригодятся во время обсуждения с консультантом команды внедрения. Не секрет – чтобы оценить, кто и насколько качественно будет делать для вас работу, необходимо как минимум запросить резюме предполагаемых кандидатов внедрения, а как максимум – встретиться с каждым и лично побеседовать. Кроме общепринятых элементов – образование, опыт работы, знания в профессиональной области, оцененные в виде не столько курсов, сколько сертификатов – полезно оценить научную деятельность, то есть публикации и околопрофессиональные интересы. Что имеется в виду? Консультант не обязан быть бухгалтером или финансовым менеджером, но он должен владеть соответствующими науками. Если у человека, который предположительно будет внедрять у вас блок «Финансы», есть сертификация СРА или CIMA в Management Accounting, значит, он – действительно ценный специалист. В практике нашей компании резюме включает поле «Публикации». Это стимулирует консультантов писать статьи и размещать их в научно-популярных изданиях. Пустота в этой графе заставляет задуматься о достаточности профессионализма.

Конечно, чем больше официальных сертификатов есть на счету у того или иного консультанта, тем выше оплата его труда. Но жизнь подсказывает, что лучше переплатить за предсказуемое качество, чем за непредсказуемые ошибки.

4.5. Как подготовиться к внедрению системы управленческого учета

Проверка боем

Все, о чем мы говорили в области постановки управленческого учета, и является подготовкой к внедрению будущей системы. Потому что к данному моменту вы создаете центр компетенции, который владеет ситуацией; знает, какие цели стоят перед внедрением управленческого учета. Людей в группу нужно подбирать, в том числе исходя из их склонности к компьютеризации и автоматизации собственного труда. Необязательно, чтобы они были ИТ-специалистами, но жилка постановщика задач необходима.

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

СМК

Существует и такой тип проекта подготовки ко внедрению системы. Если ваше предприятие занимается производством и целью внедрения управленческого учета является в том числе повышение качества обслуживания клиентов, вы можете рассмотреть вариант внедрения системы менеджмента качества (СМК). Это очень хороший подготовительный маневр, который приносит ощутимые результаты. В итоге вы должны получить от независимых экспертов сертификат по необходимому стандарту – серии ISO, ГОСТы, отраслевые стандарты.

Таблица 4.3. Этапы создания СМК

Ознакомьтесь со списком этапов, которые обязательно должен включать проект внедрения СМК (табл. 4.3), и вы поймете, что это достаточно серьезный проект, сопоставимый по времени с внедрением, по крайней мере, части комплексной информационной системы. Смысл провести его до внедрения системы управленческого учета есть: он порождает документы, которые впоследствии помогут. Вообще, чем больше документов, регламентирующих и описывающих бизнес-процессы, тем легче и быстрее пройдет внедрение системы УУ. Не придется тратить время на обследование – описывая свою деятельность, вы расставляете приоритеты. В качестве доказательств можно привести массу случаев, когда руководство просит подчиненных составить список их должностных обязанностей. Очень многих это задание повергает если не в шок, то в ступор. Потому что гораздо проще заниматься рутиной, чем ее описывать. Если рутина не описана, она, вроде, таковой и не является. А когда все описано, остается ужаснуться: «Господи! Неужели я всем этим занимаюсь каждый рабочий день?»

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

Почему такие проекты сложнее? Потому что они действительно не входят в вашу профессиональную деятельность. Все, о чем мы рассказываем в этой книге, – проекты по СМК, другие аналогичные проекты – характеризуют людей, которые ими занимаются. Они посвящают этому практически все свободное от работы время. Конечно, вы можете выделить руководителя проекта на full time (это приветствуется и станет гарантией завершения проекта в намеченные сроки и в нужном объеме). Но зачастую исполнители, эксперты, члены центра компетенции – все занимаются проектами не full time, и помимо задач проекта должны выполнять еще основные трудовые обязанности. Поэтому любой проект, осуществленный в рамках вашей организации и являющийся не основной деятельностью, очень полезен для осознания, сможете ли вы выделять дополнительное время своих людей.

Администратор

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

Мотивационная программа

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

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

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

Приведение систем стимулирования вашего персонала и персонала интегратора к единым принципам поможет создать общую команду внедрения. Часто складываются ситуации, когда консультанты работают «до последнего акта»: если нет финального документа, результаты всего проекта можно оспорить. В то время как сотрудники заказчика, выделенные на проект, получают премию за выполнение проекта, скажем, с момента запуска системы в эксплуатацию. Многие, кстати, разбивают понятие физической завершенности работы и бумажные дела. Иным кажется, что система заработала, все хорошо, акт можно подписывать, но проходит день, два, три, пять, но акт не подписывается. Возникают какие-то вопросы – мол, система работает не так, как хотелось. Консультант начинает опровергать домыслы. То ли вы неправильно составили цели, то ли консультант нечист на руку. К чему я это все говорю? Не к тому, чтобы идти у консультанта на поводу, а к тому, что подписание финального акта – признание работоспособности системы и того факта, что проект завершен. Поэтому в опытных консалтинговых организациях бонус консультантов привязан именно к данному моменту. По этой причине положение о мотивации сотрудников, задействованных на проекте, обязательно должно быть нацелено на конечную цель – подписание акта.

Ошибки мотивации персонала

Мы приводим пример проекта, который формально состоит из двух этапов. Это длительный по времени процесс, и у вас может возникнуть потребность разбить предполагаемую премию на две части: одну выплатить по окончании первого этапа, вторую – по завершении второго. В проектах внедрения комплексных систем, как и в любых других, действует принцип роста важности каждого следующего этапа. Поэтому будьте внимательны и добейтесь, чтобы основная сумма выдавалась после подписания финального акта. Иначе, взяв половину бонуса, люди не будут стараться должным образом выполнить оставшуюся часть проекта. Промежуточные выплаты, безусловно, нужны, но они должны быть мизерными по отношению к окончательной сумме (все вместе не должны превышать 40 % от предполагаемого бонуса).

Обучение пользователей

Многие компании выделяют обучение персонала в отдельный проект или вид работ. Это правильный подход. Обучение, если речь идет о десятках, а то и сотне специалистов, является сложным с координационной точки зрения процессом. Вдобавок эти люди находятся в разных офисах, а офисы часто – в разных городах и т. д. Рекомендуется обратить внимание на дистанционное обучение. Есть фирмы, которые специализируются на таких курсах. Причем делают даже то, что не входит в типовую программу. Их можно привлечь, чтобы консультант научил все ваши филиалы работе в системе. Дистанционное обучение подразумевает разные формы. Например, веб-семинар. Его главный минус – затраты на международную связь. Даже если пытаться минимизировать эти затраты с помощью IP-телефонии или Skype-технологий, далеко не везде не все каналы обеспечивают приемлемую связь. Есть и другой недостаток – отсутствие контакта с преподавателем. Здесь я хочу уберечь вас от иллюзий: немногие консультанты выделяют на обучение ценных, опытных специалистов, которые могут ответить на широкий круг вопросов. Это естественный ход вещей. Успешная консалтинговая компания продает новые проекты, хотя не всегда успевает за темпом их появления. Отсюда – дефицит квалифицированных работников. Держать опытного консультанта лишь для обучения невыгодно. Если проект внедрения продан, речь идет о большом долгосрочном контракте. Все фазы, вопросы взаимодействия и вовлечения других специалистов в нем предопределены. Обучение же, если оно продается как отдельный продукт, менее предсказуемо, поскольку сам проект меньше по объему. Гораздо легче предсказать, где будет занят сотрудник на проекте внедрения, поскольку это продлится минимум шесть месяцев. А что он будет делать на проекте обучения в одну неделю? Спланировать такую неделю в течение полугода очень непросто. Именно поэтому на обучение вы можете и не получить высококачественный учебный материал. Под качеством мы понимаем, что нам дадут нечто большее, нежели «сухой» учебный материал по теме.

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

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

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

Е. Плаксенков: «Нужно принять как факт, что у людей существует определенная скорость принятия нового. Например, по ходу развития компания решилась выставить какие-то небывалые требования к финансистам. Начали увольняться те, кто не хочет их выполнять. Сразу стали набирать других, лояльных к системе. Заявив на входе о принятии условий, такие сотрудники не могут не поддержать новую систему. Им говорят: «Мы внедряем такую-то систему. Критерий качества вашей работы – отношение к ней и скорость внедрения». Так мгновенно задается иная динамика, с которой внедрение проходит гораздо быстрее. Но для этого надо принять решение, что ты отказываешься от прежнего персонала в пользу новых людей. Если возможность есть – флаг в руки. Бизнес – не просто работа, это жизнь.

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

А вот пример диаметрально противоположного подхода от сети аптек «36,6»:

Б. Рябов: «Мы использовали особый вид мотивации при запуске системы – безальтернативная. С самого начала было сказано: «Что бы ни произошло, с такого-то числа вы работаете в новой системе». Все мосты сожжены. Это – эффективная мотивация. Мотивация обратного характера в случае внедрения системы – большая редкость, поскольку она не всегда возможна. Проблема в том, что возникают моменты, когда нельзя повернуть назад. Люди начинают работать сутками не потому, что им заплатят, а потому, что если они сейчас этого не сделают, потом не смогут работать. Смесь страха, ответственности и совести. Самое главное – донести идею безальтернативности; от вашего бездействия проект не остановится, но из-за проблем проекта ваша деятельность может серьезно осложниться».

4.6. Методология внедрения

Подход к созданию АСУП. Описание методики

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

Внедренный управленческий учет = Построенная и эксплуатируемая АСУП АСУП = Настроенное бизнес-приложение + «Настроенные» люди Связь между программным средством и системой

Система является комбинацией технических средств, компьютеров, программных средств, материалов, персонала и возможностей, как показано на рис. 4.2. Все это фактически образует работоспособную систему. В исходной системе существуют реальные процессы. Программные средства обеспечивают выполнение некоторых функций данных процессов на компьютерах. Они могут быть постоянно (резидентно) размещены в компьютерах, встроены как программы, реализованные техническими средствами, или интегрированы в объект технических средств. В любом случае заказ, поставку, разработку, эксплуатацию или сопровождение программных средств необходимо координировать и гармонизировать с аналогичными процессами для исходной системы.

Рис. 4.2. Связь между программным средством и системой

Вашему вниманию предлагается концептуальное описание методических подходов к созданию АСУП с применением типовых проектных решений (ТПР, в том числе отраслевые решения). ТПР – бизнес-приложение или комплекс приложений, настроенных для решения определенного перечня бизнес-задач. Эти задачи носят тиражируемый характер и могут быть востребованы многими компаниями. Например, отраслевое решение – типичный ТПР. Он представляет собой готовое решение (проектные и эксплуатационные документы, модели, алгоритмы, программный код, схемы данных, классификаторы), которое может значительно сократить затраты времени и ресурсов дать принципиальное согласие на приведение процессов своей фирмы в соответствие со структурой, программной логикой, форматами данных и классификаторами, используемыми в ТПР. Обоснованное решение о возможности использования ТПР может быть принято лишь по результатам предпроектного обследования вашего предприятия с привлечением консультантов и других специалистов, обладающих необходимыми знаниями предметной области, функциональных возможностей и ограничений ТПР.

Данные методические подходы основаны на проектном опыте консалтинговых компаний, внедряющих бизнес-приложения, российских и международных стандартов и методик в области проектирования.

При описании учитывались следующие допущения:

• В ходе проекта максимально задействуются специалисты заказчика; особенно в задачах, связанных с эксплуатацией и сопровождением системы.

• Методики не покрывают вопросы проектирования инфраструктурных ресурсов: аппаратного обеспечения, телекоммуникаций и т. п.

Классификация функций АСУП

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

Классификатор реализуемых в АСУП функций должен быть составлен таким образом, чтобы вам и вашим консультантам было понятно не только, что именно автоматизируется, но и что делать не нужно. Использование стандартизованной функциональной структуры АСУП позволяет избежать проблем, связанных с несоответствием проектных ожиданий заказчика.

Выбранный классификатор должен иметь иерархическую структуру. В частности, следует однозначно определить, что в подсистему «Управление финансовыми ресурсами» входит (или не входит):

• ведение бухгалтерского учета (ведение главной книги, кассовых операций, банковских счетов; формирование регламентированных отчетных документов: бухгалтерский баланс, отчет о прибылях и убытках и т. п.; подготовка счетов, платежных документов, расчет заработной платы);

• ведение налогового учета;

• расчет себестоимости продукции, остатков незавершенного производства;

• мониторинг основных производственных процессов и производственных показателей;

• кредитный менеджмент;

• управление основными средствами, нематериальными активами.

Стадии ЖЦ АСУП

Состав стадий ЖЦ АСУП

Жизненный цикл создания АСУП состоит из стадий, перечисленных в табл. 4.4.

Таблица 4.4. Стадии жизненного цикла АСУП

Стадии 1 и 7 жизненного цикла проектирования системы здесь подробно не описываются. Потому что состав работ по первой стадии всегда индивидуален. Их цель – определить с максимальной точностью рамки проекта. А стадия 7 «Эксплуатация АС» фактически относится к ЖЦ системы как таковой, и указана здесь для полноты картины, так как достоверным критерием внедрения является ее реальная эксплуатация.

Завершение каждой стадии фиксируется актом сдачи-приемки работ. Проект по созданию и развитию АСУП в зависимости от состояния системы и выполненных ранее проектов может включать разные стадии.

При использовании ТПР можно исключать из проекта задачи, работы и целые стадии, если соответствующие решения уже есть в готовом виде в ТПР.

Рис. 4.3. Жизненный цикл проекта по созданию АСУП

Если после исключения задач оказывается, что состав работ какой-либо стадии минимизирован до предела, ее выделение в проекте может стать бессмысленным. В таком случае стадии следует объединять. Возможно объединение стадий: A + B, C + D. Другие стадии объединять нельзя (табл. 4.5).

Таблица 4.5. Наименование объединенных стадий

Стадия A. Определение требований

Цели и задачи стадии

В результате выполнения работ стадии должны быть достигнуты следующие цели:

• согласованность связанных целей бизнеса и автоматизации;

• заинтересованность высших руководителей в проекте;

• определенность недостатков существующих процессов и информационной системы;

• корректное понимание задач, которые требуется решить в проекте для достижения бизнес-целей;

• вывод о возможности и целесообразности решения бизнес-задач выбранными средствами;

• снижение рисков проекта путем более детального (по сравнению с договором) определения логических рамок автоматизируемых бизнес-процессов;

• определенность источников эффективности проекта;

• сопоставление существующих процессов с решениями, заложенными в программных приложениях;

• согласованная оптимизированная модель бизнес-процессов, учитывающая принятую программную платформу и доступные способы автоматизации функций;

• согласованное понимание рамок проекта и детальный (по следующей стадии) план проектирования[20].

Состав работ по этапам

Таблица 4.6. Состав работ стадии «Определение требований»

Рекомендации по выполнению работ

Этап A1. Планирование и организация работ проекта

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

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

Выходные документы стадии «Определение требований»:

• планирование и организация работ проекта (требования заказчика);

• сбор и анализ данных (описание существующей информационной инфраструктуры);

• формирование концепции проекта;

• постановка задачи (отчет об обследовании объекта);

• завершение определения требований.

Далее проводится встреча рабочей группы проекта (или ее руководителей) с высшим руководством вашей компании для выявления и согласования:

• уточненных логических рамок и целей проекта создания АС;

• используемого подхода;

Рис. 4.4. Этапы работ стадии «Определение требований»

• основных проблем или областей возможной оптимизации бизнеса;

• состава ответственных представителей по вопросам проекта;

• порядка работы с руководителями подразделений.

Менеджер проекта согласовывает состав группы внедрения и план встреч со специалистами клиента, организует предоставление информации по стратегии, существующим бизнес-процессам и информационной системе.

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

Этап A2. Сбор и анализ данных

На основе данных «Предпроектного обследования» выполняется анализ архитектуры бизнес-процессов, в ходе которого необходимо разработать верхнеуровневое описание существующих процессов (BP.070 «Описание процессов»). Должна быть документирована информация по составу автоматизируемых функций БП, составу необходимых АРМ и планируемых изменениях в БП. Также собирается информация о необходимых рабочих местах пользователей и инфраструктуре объекта. Документ может быть оформлен как часть отчета об обследовании. Если вы проектировали оперативный учет, основным источником сведений для данного этапа является перечень документов, которые вы разработали:

• бизнес-функции;

• бизнес-процессы;

• перечень объектов и субъектов оперативного учета.

На основе описания процессов проводится обследование предприятия с целью определить комплексные бизнес-требования.

В ходе обследования рекомендуется такая последовательность работ:

• (при отсутствии постановки ОУ) на основании списка обследуемых бизнес-процессов проводятся интервью с ответственными за процессы (владельцами процессов) на предприятии;

• (при отсутствии постановки ОУ) анализируются существующие на предприятии формы документов; формируется «Ведомость первичных документов» в виде отдельного приложения к отчету об обследовании; первичные документы собираются по структурным подразделениям (входящие/исходящие);

• выясняются пожелания пользователей будущей системы (начиная с руководства) относительно модификации старых отчетов и создания новых;

• собирается формализованная информация: органиграммы, схемы площадок, схемы корпоративной сети, функциональные и структурно-технические схемы существующей ИС, модели процессов и т. п.;

проводится обследование существующей ИС на предмет выяснения недостатков и предлагаются возможные пути их устранения; не требуется глубокое изучение информационной инфраструктуры;

• на основании интервью проводится детализация целей бизнес-процессов и ИС до уровня измеримости; выясняются критерии их достижения; дерево целей удобно представить в виде таблицы;

• на основе стандартной классификации и полученных данных о функциональной структуре описываются функции бизнес-процессов 2–3 уровня.

1. Информационный анализ

Необходимо в минимальном виде проводить информационный анализ выходных информационных потоков (например, отчетности), входных информационных потоков (например, первичных документов) с целью определения:

• достаточности входных информационных потоков для получения выходных;

• непротиворечивости, дублирования информационных потоков;

• унификации информационных потоков и форм документов;

• соответствия информационных потоков логическим рамкам проекта (структура информации, состав реквизитов документов).

2. Построение дерева целей

Сначала для существующих бизнес-процессов определяются цели верхнего уровня. Необходимо помнить, что цели бизнеса и цели построения АСУП – разные по своей природе цели. В идеале, за основу целеполагания проекта в вашей организации берется существующая система целей и показателей (ССП и т. п.). Затем определяются цели будущей автоматизированной системы и проводится их квантификация (детализация с выполнением требований полноты, корректности, независимости и непротиворечивости) до уровня когда:

• критерии достижения цели становятся измеримыми;

• цели системы связаны и согласованы с целями бизнес-процессов.

При построении дерева целей необходимо, насколько это возможно, придерживаться правила независимости целей одного уровня друг от друга. Цели должны формулироваться просто, с низким уровнем иерархии. Их количество должно быть сведено к минимуму. Дерево целей следует согласовать с руководством заказчика.

Доказательство необходимости проектирования системы строится на соотнесении целей создаваемой системы и целей бизнеса, а также на источниках экономической эффективности.

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

Общая методика целеполагания изложена в главе 2 «Управленческое планирование».

3. Построение моделей

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

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

Форма представления моделей может быть графической или в виде текстового описания.

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

Этап A3. Формирование концепций проекта

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

Этап A4. Постановка задачи

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

Оформляется и согласовывается «Отчет об обследовании предприятия».

Утверждение «Отчета об обследовании объекта» заказчиком обычно не требуется, так как этот документ является информационным (не устанавливает требований). Рекомендуется после представления отчета провести презентацию итогов работ стадии для руководства вашего предприятия.

Отличия при использовании ТПР

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

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

Полученная информация и принятые для использования ТПР решения должны быть систематизированы, четко сформулированы в стандартных документах и согласованы с заказчиком до дальнейшего использования в проекте.

Стадия B. Системное проектирование

Цели стадии

Основными целями стадии являются:

• определение организационных, функциональных, информационных и эксплуатационных требований к системе;

• проработка автоматизируемых информационных процессов до уровня элементов инфраструктуры;

• отражение бизнес-требований через возможности программных приложений;

• демонстрация осуществимости проектируемых бизнес-процессов для вашего предприятия;

• определение требований к персоналу, регламенту и информационной инфраструктуре;

• предложение способа перехода на новую систему;

• определение требований по интеграции с другими системами и приложениями.

Состав работ по этапам

Таблица 4.7. Состав работ стадии «Системное проектирование»

Рис. 4.5. Этапы работ стадии «Системное проектирование»

Выходные документы

• планирование работ по созданию АС – план подготовки объекта;

• разработка технического задания – техническое задание на создание АС;

• завершение системного проектирования – акт приемки-сдачи работ.

Рекомендации по выполнению работ

Этап B1. Планирование системного проектирования

При организации работы группы внедрения необходимо создать среду для возможного прототипирования (см. «Прототипирование» далее) и использования прототипа для установления требований заказчика (отражения бизнес-требований).

Этап B2. Анализ и оптимизация системных требований

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

Прототипирование

Используется для уточнения требований к системе, демонстрации ее возможностей и способа отражения бизнес-требований.

Прототип приложения может строиться на основе стандартной версии программ из состава программной платформы или с использованием прототипа из состава ТПР. Он служит действующей имитационной моделью системы.

Полезно использовать прототип для демонстрации и отладки процедур взаимодействия со смежными системами (фронт-офис, клиент-банк, АСУТП, САПР и т. п.) путем запуска прототипа на опытном стенде с использованием средств интеграции и сбора данных: кассовых аппаратов; систем электронного документооборота, идентификации и контроля доступа, промышленной автоматики и т. п.

Рекомендуется начать использовать прототип как можно раньше. Это позволит более точно определить требования ключевых пользователей к будущей системе и ее интерфейсам.

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

Основные проектные задачи, решаемые с помощью прототипирования:

• согласование модели TO-BE как иллюстрации способа отражения требований;

• проверка возможности реализации бизнес-требований;

• проверка и отладка способов интеграции с внешними системами;

• оценка трудоемкости реализации.

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

Планирование доработок

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

Рекомендуется вести «План доработок», начиная со стадии «Системное проектирование» и до момента их полного выполнения на стадии «Реализация АС».

Планирование конвертирования

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

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

Нужно планировать следующие основные задачи конвертирования данных:

1. Назначить ответственных за конвертирование.

2. Определить требования к конвертированию данных.

3. Разработать схемы и алгоритмы конвертирования.

4. Разработать процедуры ручного конвертирования и ввода данных.

5. Разработать и протестировать средства конвертирования.

6. Проверить корректность и подготовить начальные данные к конвертированию.

7. Планировать ресурсы, время, последовательность конвертирования (план-график).

8. Организовать и провести конвертирование в соответствии с планами проекта.

9. Выполнить проверку полученных данных.

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

Этап B3. Планирование работ по созданию АС

Подготовка ключевых пользователей

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

Подготовка объекта к вводу системы в действие

Для успешного запуска АСУП недостаточно просто выполнить работы по ее созданию. Надо – до начала стадии «Ввод в действие» – провести техническую и организационную подготовку самого объекта. Эти работы должны планироваться на «Системном проектировании».

Техническая подготовка объекта включает:

1. Разработку заданий на проектирование в смежных областях.

2. Разработку технического регламента.

3. Подготовку обслуживающего персонала.

4. Закупку комплектующих.

5. Разработку и реализацию инфраструктуры нижних уровней.

6. Запуск процесса эксплуатации и управления информационными ресурсами.

Организационная подготовка объекта включает:

• Создание структурных подразделений и изменение существующей оргструктуры.

• Включение новых функций в обязанности служб.

• Создание новых должностных позиций.

• Инструктаж персонала организации (не персонала проекта внедрения АСУП), чья деятельность может измениться после запуска системы.

• Выделение персонала для работы в группе внедрения.

• Оповещение персонала организации об изменениях технологии и регламента работ.

• Мотивацию персонала и т. д.

Этап B4. Разработка технического задания

Типовое содержание ТЗ приведено на прилагаемом к данному руководству CD. Техническое задание является главным документом, на базе которого создается система. Готовое техническое задание утверждается заказчиком и служит формальным основанием для подписания акта приемки-сдачи работ по стадии «Системное проектирование».

Стадия C. Техническое проектирование

Цели стадии

Основными целями стадии являются:

• проект доработок приложений системы;

• проект конвертирования данных;

• проект настроек приложений;

• техпроект инфраструктуры;

• проект организационной структуры;

• среда для выполнения доработок приложений и конвертирования данных.

Состав работ по этапам

Таблица 4.8. Состав работ стадии «Техническое проектирование»

Рекомендации по выполнению работ

Этап C1. Планирование технического проектирования

При организации работы группы внедрения необходимо создать среду для возможного прототипирования и использования прототипа для согласования проектных решений.

Этап C2. Проектирование приложений

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

Проектирование приложений является основой технического проектирования системы. Этих работ может и не быть (отсутствие доработок, использование ТПР). В данном случае имеет смысл объединить стадии (C + D) в одну «Реализация АС».

Этап C3. Проектирование инфраструктуры

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

Для проектирования инфраструктуры нужно предоставить заказчику следующие исходные данные:

• структуру (состав элементов) системы;

• требования к техническому обеспечению;

• требования к вычислительному, транспортному и физическому слоям инфраструктуры;

• требования к информационному обмену между компонентами системы;

• требования к хранению, восстановлению, контролю данных;

• требования к надежности (если есть);

• план загрузки мощностей системы;

• план подготовки объекта к вводу системы в действие;

• план-график проекта, включающий даты готовности инфраструктурных подсистем;

• план размещения приложений и БД.

Вся перечисленная информация должна быть в ТЗ.

Этап C4. Проектирование организационной структуры

Разработка решений по организационной структуре должна выполняться в соответствии с требованиями ТЗ к персоналу и регламенту АС.

Необходимо закрепить функции («роли») пользователей за подразделениями и должностными позициями.

Решения по организационной структуре отражаются в пояснительной записке (раздел 6) или в отдельном документе «OD.003 Описание организационной структуры» (см. ГОСТ).

Этап C5. Разработка технического проекта

Технический проект – комплект проектных документов, описывающих принятые для выполнения технических требований проектные решения. На основе техпроекта осуществляется реализация (построение) системы.

Этап C6. Завершение технического проектирования

Подводятся итоги стадии, оценивается качество выполненных работ, высвобождаются использованный персонал и инфраструктура (рис. 4.6).

Работы стадии «Реализация АС» могут быть начаты до окончания технического проектирования, но только по документально согласованным частям (например, отдельным заданиям на разработку).

Рис. 4.6. Этапы работ стадии «Техническое проектирование»

Выходные документы

• описание среды реализации;

• пояснительная записка к техническому проекту;

• акт приемки-сдачи.

Отличия при использовании ТПР

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

Стадия D. Реализация АС

Цели стадии

Результатом «Реализации АС» должно стать достижение следующих целей:

1. Готовность протестированных программных разработок, включая: доработки программных приложений, интерфейсные программы, программы конвертирования данных, смежные интегрируемые программы.

2. Подтвержденное соответствие производительности системы.

3. Завершенность запланированных оргструктурных мероприятий.

4. Готовность требуемых инфраструктурных подсистем.

5. Готовность эксплуатационной документации.

6. Готовность программы и методики испытаний.

7. Готовность среды для проведения испытаний.

8. Готовность средств и среды обучения пользователей.

9. Обученные ключевые пользователи.

10. Завершенность сборки, проверки и выпуска системы.

Состав работ по этапам

Таблица 4.9. Состав работ стадии «Реализация АС»

Рекомендации по выполнению работ

Этап D1. Планирование реализации

Состав работ первых трех стадий в значительной степени предопределен структурой разрабатываемых на них проектных документов: отчет об обследовании, ТЗ, пояснительная записка к техническому проекту.

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

Этап D2. Реализация приложений

Отслеживание состава доработок

Необходимо строго отслеживать состав выполняемых доработок. Любая попытка навязать выполнение не предусмотренных проектом работ должна пресекаться менеджером проекта. Допускаются замены одного вида доработок другими, не более трудоемкими.

Этап D3. Реализация инфраструктуры

Кроме создания эксплуатационной среды АСУП нужно контролировать создание среды для испытаний системы и обучения пользователей. Это не всегда одно и то же. Например, при большом количестве пользователей может потребоваться учебный класс или проекционное оборудование.

Этап D4. Разработка эксплуатационной документации

Эксплуатационные документы предназначены для организации эффективного и безопасного использования системы по назначению и обеспечения надежности ее функционирования.

Основные эксплуатационные документы должны позволять идентифицировать АС, вести инвентарный учет элементов системы, управлять ее конфигурацией, планировать развитие, интеграцию или утилизацию АС.

Часто по результатам стадии «Реализация АС» требуется выпустить описательную документацию – аналог исполнительной документации в строительстве. Реализованная система может отличаться от проектной конфигурации, описанной в техпроекте, на уровне деталей. Такие изменения могут быть внесены, например, по результатам испытаний.

Этап D5. Реализация организационной структуры

В соответствии с требованием ТЗ внутри компании разрабатывается и публикуется вся необходимая организационно-методическая документация: должностные инструкции, положения о структурных единицах, процедуры процессов, политика безопасности и т. п. Обучение проходят ключевые пользователи. Его полезно совмещать с настройкой приложений прототипа. Ключевые пользователи обучаются функциональности системы в группе внедрения под руководством менеджера проекта. Обучение общего характера (например, по изучению программной платформы в учебном центре) может быть начато как угодно рано (например, на стадии «Системное проектирование»). А завершить его можно лишь на стадии реализации, когда структура пользователей становится известна полностью (на уровне персоналий).

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

Этап D6. Сборка АС

Документ «Программа и методика испытаний» (см. содержание в приложениях на CD) (ПиМ) разрабатывается в соответствии с требованиями к тестированию АС, прописанными в ТЗ.

В документе определяются этапы испытаний; документы, разрабатываемые на всех этапах; представляются методика и сценарии тестирования АС. Основная задача разработки ПиМ – обеспечить тестовое покрытие для всех функций системы. При этом надо указать не только способы проверки каждой функции, но формальные критерии выполнения тестов, условия проведения испытаний и тестовые наборы данных.

Виды испытаний АСУП:

• Предварительные испытания – проводятся для доказательства работоспособности системы и подтверждения ее комплектности на момент запуска в опытную эксплуатацию. Цель предварительных испытаний – предотвратить остановку системы после начала опытной эксплуатации для ее доработки.

• Опытная эксплуатация – проводится для проверки соответствия созданной системы требованиям, предъявленным к ней в ТЗ. Это обязательный вид испытаний. Его задачей является переход к промышленной эксплуатации без остановки системы.

• Приемочные испытания – проводятся для подтверждения готовности эксплуатируемой в опытном режиме системы к промышленной эксплуатации.

Содержание испытаний описано в разделе «Рекомендации по выполнению работы» (стадия «Ввод в действие»).

На данном этапе осуществляются комплектация и сборка системы: все элементы устанавливаются в реализованной инфраструктуре в необходимой конфигурации, выполняется локальная пуско-наладка (рис. 4.7). Фактические комплектность, конфигурация, результаты наладки регистрируются соответствующими записями комплектации и наладки. Должны быть документированы комплектность, версии, дислокация и настройки всех элементов системы.

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

При необходимости, если производительность ключевых функций АС является критичным параметром (требования ТЗ), может проводиться дополнительное тестирование производительности системы – в соответствии со специально разрабатываемыми требованиями и по спецпрограмме в конце стадии «Реализация АС».

Этап D7. Завершение реализации

На основании записей комплектации и наладки, эксплуатационной документации и факта выполнения комплексной пуско-наладки подписывается акт приемки-сдачи работ по стадии «Реализация АС».

По результатам стадии принимается решение о приемке системы в опытную эксплуатацию. На стадии «Ввод в действие» это решение должно быть закреплено соответствующим приказом.

Изменение требований

Необходимо отслеживать изменение требований к системе и проектных решений. Любое изменение возможно только после оценки его реализации и допустимости, внесения соответствующих поправок в спецификации проекта (в ТС и ТЗ – в виде дополнений). Все масштабные доработки, не включенные в проект и не отраженные в проектной документации (в том числе, если вы решили платить за них отдельно), должны выноситься за его рамки: на следующие проекты или период сопровождения.

Выходные документы

• уточнения консультационной документации;

• журнал установки среды для тестирования;

• описание среды тестирования и обучения;

• программа и методика испытаний;

• разрешение на выпуск;

• акт приемки-сдачи;

• эксплуатационная документация.

Рис. 4.7. Этапы работ стадии «Реализация АС»

Управление конфигурацией

Изменения, реализуемые в системе и ее элементах, надо отражать в соответствующей проектной и эксплуатационной документации.

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

Процесс эксплуатации

Перед выпуском системы и до начала испытаний необходимо добиться, чтобы обслуживающий персонал вашей компании принял на себя обязанности, связанные с процессом эксплуатации системы:

1. Управление учетными записями и правами доступа пользователей.

2. Контроль соблюдения пользователями правил работы с системой и обучение, консультирование пользователей этим правилам.

3. Эксплуатационная настройка и наладка режимов работы системы.

4. Задание режимов, запуск и контроль выполнения регламентированных функциональных задач системы, выполняемых в пакетном режиме (резервное копирование, архивация, печать регламентированных отчетов, закрытие операционного дня и т. д.).

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

6. Выполнение регламентных работ по поддержке работоспособности системы, доступности ее функций, целостности и конфиденциальности информации.

7. Выполнение ремонтно-восстановительных работ при авариях и отказах системы; нарушении режимов ее работы; снижении степени защиты, надежности, безопасности, производительности или эффективности (за пределами установленного уровня).

8. Выполнение работ по плановому развитию и модернизации системы.

Стадия E. Ввод в действие

Цели стадии

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

Для достижения цели стадии необходимо:

1. Завершить обучение пользователей.

2. Конвертировать или ввести актуальные данные.

3. Создать вместе с консультантами приемочную комиссию.

4. Утвердить «Программу и методику испытаний».

5. Провести испытания, исправить ошибки и устранить замечания.

6. Передать управление конфигурацией заказчику.

7. Закрыть договор.

Подробнее работы и задачи стадии изложены в следующем подразделе.

Состав работ по этапам

Таблица 4.10. Состав работ стадии «Ввод в действие»

Рекомендации по выполнению работ

Этап E1. Планирование ввода в действие

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

Этап E2. Подготовка испытаний

Подготовка является наиболее ответственным и требующим повышенного внимания со стороны менеджера проекта этапом испытаний. От того, как выполнена подготовка, во многом зависит конечный результат.

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

Придание правового статуса испытаниям

Для проведения испытаний приказом генерального директора вашего предприятия создается полномочная приемочная комиссия, обладающая, как правило, статусом совместной комиссии.

Обычно в ее состав входят три-пять человек, в том числе один-два специалиста – от исполнителя и два-три – от заказчика. Председателем приемочной комиссии назначается председатель координационного комитета – представитель заказчика (из числа членов комиссии).

Задачами приемочной комиссии являются:

• принятие АС в опытную эксплуатацию с подписанием акта приемки в опытную эксплуатацию;

• утверждение документа «Программа и методика испытаний»;

• подготовка документа «Приказ о начале опытной эксплуатации» и организация испытаний;

• отслеживание записей в документе «Журнал опытной эксплуатации» и ведение документа «Протокол тестирования»;

• разработка документа «Протокол согласования»;

• принятие решений по ходу и результатам испытаний;

• приемка в промышленную эксплуатацию, подписание акта приемки в промышленную эксплуатацию.

Приемочная комиссия утверждает программу и методику испытаний, организует испытания. Все дальнейшие решения по ходу испытаний подтверждаются приемочной комиссией.

Обучение конечных пользователей

Обучение конечных пользователей организуется и проводится вашими силами (при наличии бюджета можно привлечь подрядчиков) с использованием обученных ранее ключевых пользователей.

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

Конвертирование данных

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

Этап E3. Предварительные испытания

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

Выявленные в ходе предварительных испытаний ошибки реализации должны быть устранены до начала опытной эксплуатации.

Этап E4. Опытная эксплуатация

Начало опытной эксплуатации фиксируется актом приемки в опытную эксплуатацию (ГОСТ) или приказом заказчика по предприятию.

Минимальная длительность опытной эксплуатации – один месяц.

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

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

То, что невозможно исправить в определенные договором сроки, оговаривается в протоколе согласования, где указываются:

• невыполненные (неисправленные) к окончанию стадии «Ввод в действие» требования (замечания);

• список требований (замечаний), которые не будут устраняться исполнителем;

• сроки выполнения (исправления) тех требований (замечаний), которые должны быть выполнены (исправлены) после окончания приемочных испытаний.

Этап E5. Приемочные испытания

Приемочные испытания проводятся в соответствии с утвержденной программой и методикой испытаний (см. приложение 6.3).

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

Этап E6. Завершение проекта

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

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

Составляется паспорт проекта.

По результатам стадии вы должны будете самостоятельно принять решение о приемке системы в промышленную эксплуатацию.

Систему запускает не консультант, а предприятие.

Особые замечания и советы

Цели целям рознь

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

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

О необходимости обследования

Если вы действительно проектировали УУ, львиная доля работы по обследованию (и даже часть работ по системному проектированию) вами уже проделана. Но обследование все равно придется провести, так как консультантам нужно ознакомиться с вашими документами.

Если вы внедряете систему самостоятельно, вам все равно не обойтись ни без методологии внедрения, ни без обследования собственной компании.

Бизнес-процессы

На данный момент вам может показаться, что руководство предлагает вам заниматься двойной работой: описывать БП как на этапе проектирования УУ, так и на этапе технологического обеспечения (внедрения) УУ. Тем не менее, представленные инструкции по описанию БП не только на первый взгляд противоречат друг другу. Во-первых, проектирование и автоматизация УУ могут быть отдельными самостоятельными проектами. Выполнение одного из них не обязывает вас браться за другой. Можно спроектировать УУ в «минимальном» режиме, описывая только бизнес-функции. Тогда вам пригодится полноценное описание методологии внедрения АСУП. Или, если вы все-таки описали во всех подробностях свои БП при проектировании УУ, вы сами сможете определить степень детализации их описания на этапе автоматизации. Зачастую между проектированием и внедрением УУ проходит определенное время, поэтому понятие «описание БП» во время внедрения вы можете заменить на «актуализацию описания БП».

Рис. 4.8. Этапы работ стадии «Ввод в действие»

Кроме того, не стоит забывать, что исполнителями обоих этапов в 90 % случаев являются разные консалтинговые компании.

Сложность архитектурных уровней

У системы управления есть множество инфраструктурных уровней:

• сетевая;

• информационная;

• вычислительная;

• прикладная;

• инженерная;

• организационная.

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

Два важных замечания о ТЗ

Техническое задание – это не задание консультанту. ТЗ – свод требований к системе и планов по ее созданию (развитию). Это единственный технический документ, актуальность которого должна поддерживаться на протяжении всего проекта. Если бы ТЗ являлось заданием консультанту, его никто бы не читал и не актуализировал. Оно должно быть руководством для всех заинтересованных сторон, принимающих участие в проекте. И, кстати, ТЗ – единственный технический документ, легитимность которого подтверждает Гражданский кодекс РФ.

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

Самостоятельное внедрение

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

Тестирование

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

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

Дополнительные требования

На стадии технического проектирования и последующих в 80 % случаев возникают дополнительные требования к разрабатываемой системе. Потому что только начиная с этих стадий вы реально знакомитесь с системой. Кроме того, бизнес, конъюнктура рынка и прочие условия (читай – ваша компания) к этому времени могут измениться. Число дополнительных заданий на разработку не должно превышать определенного порога от функционала, который изначально был заложен в систему. Вернее, не превышать процента, который вы спрогнозировали с консультантом. На российском рынке нормальный процент доработок бизнес-приложения класса ERP равен 20 %.

Сколько платить за опытную эксплуатацию

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

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

Как запустить систему?

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

Еще раз о прототипе

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

И не забывайте, что прототип необходимо использовать на протяжении всей разработки вплоть до окончания реализации.

О методологии вендора

У каждого крупного и серьезного разработчика бизнес-приложений есть своя методология внедрения. Ее использование имеет свои плюсы и минусы.

Рис. 4.9. Сравнение методик проектирования

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

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

Кстати: всегда нужно говорить об обеспечении (и/или управлении) качества, а не о его контроле. Контроль недостаточен и сам по себе в большом проекте малоэффективен.

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

Не рассмотрены здесь и вопросы, касающиеся системного и процессного подхода к управлению ИТ на предприятии. Эти подходы – основа современного менеджмента (отражено во всех стандартах). Проект по созданию АСУП – лишь первый шаг, который нужно предпринять в череде процессов, связанных в единый жизненный цикл ИТ на предприятии.

Зависимость необходимости в автоматизации от зрелости компании

В какой момент своего развития компания нуждается в том или ином инструменте автоматизации управленческого учета? Как зависит выбор методологии внедрения бизнес-приложения от степени зрелости вашей фирмы?

Развитие компании хорошо показано на диаграмме, составленной «Harvard Business Review» (рис. 4.10). Здесь отображены пять фаз зрелости (размера).

Рис. 4.10. Стадии зрелости организации

В целях наглядности мы представили примерные сроки возникновения необходимости в автоматизации той или иной управленческой задачи в табл. 4.11.

Таблица 4.11. Соотношение фаз развития организации и необходимости в автоматизации

Главным риском фазы «Делегирование» является «Контроль». Именно на этой фазе развития обычно приступают к автоматизации функций управленческого планирования, оперативного учета и т. д.

Если вы находитесь в фазе два («Направление»), максимум, что вам потребуется – внедрение «легкой» учетной системы. Дойдя до фазы «Делегирование», вы почувствуете потребность в бюджетном планировании и сможете надстроить уже имеющуюся у вас систему учета системой класса BPM. Фаза четыре («Координация») – время для принятия решения в пользу серьезной комплексной системы. На этом этапе многие компании начинают менять «легкое» учетное приложение на более «тяжелую» ERP-систему. И, поскольку на постановку и внедрение УУ обычно отводится большой срок, за время этого проекта компания переходит в фазу «Сотрудничество», находиться в которой без автоматизированного управленческого учета просто невозможно.

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

1) обследование – интервью экспертов участка;

2) настройка и приемка прототипа – приемка фиксируется протоколом, в котором перечислены все настройки прототипа. Впоследствии протокол послужит аналогом технического задания;

3) окончательная настройка приложения для участка;

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

Как вы уже поняли, управленческий учет связывает сотрудников организации в едином информационном пространстве, бюрократизирует и автоматизирует процессы. По сути, автоматизация – это «продвинутая» бюрократизация взаимодействия субъектов учета между собой.

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

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

Описания фаз

Первая фаза, характеризующая маленькие и молодые компании, подразумевает стиль управления, основанный на творчестве. Главным движущим фактором являются идеи, рожденные в голове лидера компании. Лидерство и становится источником кризиса: неправильная идея принадлежит именно ему; больше ничьи идеи не воспринимаются, а если и берутся в расчет, то интерпретируются лидером по-своему.

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

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

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

Пятая фаза – это сотрудничество. Оно наступает, когда в фирме вполне осознанно появляются такие институты, как совет директоров, дочерние предприятия, самостоятельные филиалы и т. д.

Е. Плаксенков: «Управленческий учет есть в любой компании. Если его все-таки нет, значит, отсутствует понятие «системный бизнес». Работа ведется по «шуточному» принципу: купил-продал-израсходовал. Это спонтанный и недолгосрочный бизнес. Даже на самых ранних стадиях развития в компании есть управленческий учет. Прежде чем начинать реальный и системный бизнес, необходимо продумать финансовую сторону. С этого момента и появляется управленческий учет – вместе с желанием построить свое дело. Ведь любое желание неминуемо имеет финансовую сторону. Если бизнес поставлен на долгосрочной основе, в нем есть управленческий учет.

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

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

4.7. Устав проекта

Устав проекта закрепляет организационную структуру, регламент его ведения, а также содержит общее для заказчика и исполнителя понимание того, как решать проблемы в ходе проекта и как принимать решения, если до полного исполнения проекта невозможно определить его рамки (см. пример устава проекта – приложение 6.4 и в электронном виде на CD). Порядок внесения изменений в устав проекта указывается в первом разделе устава. Здесь же прописываются цели проекта и критерии их достижения.

Второй раздел устанавливает рамки проекта. Можно выделить логические, технические, географические и временные рамки, а также проектные риски:

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

• Географические рамки – место осуществления внедрения (название компании или филиала, указание региона).

• Временные рамки проекта определяются, исходя из временных рамок каждой стадии проекта, которые приведены в разрезе дат, состава работ и результата.

• Средство реализации целей проекта – это название внедряемых бизнес-приложений и название проектируемой АСУП.

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

Третий раздел касается организационной структуры проекта.

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

Управление проектом

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

Порядок проведения собраний проектной команды

Собрания проводятся на уровне координационного комитета и рабочей группы. Периодичность их проведения, цели и документированные решения определяются в данном пункте.

Порядок ведения проектной документации

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

• план проекта;

• устав проекта;

• техническое задание;

• пояснительная записка к техническому заданию;

• руководство пользователя;

• руководство администратора;

• техническое описание настроек системы;

• журналы тестирования;

• протокол проведения опытной эксплуатации;

• акт приемки системы в промышленную эксплуатацию.

Вся текущая проектная документация должна храниться в специальной базе данных. Отдельно оговаривается доступ к этим документам, а также условия внесения в них изменений.

Процедуры согласования

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

Контроль и отчетность по исполнению планов

По результатам исполнения планов работ формируются отчеты о текущем состоянии работ. Менеджеры проекта могут отслеживать состояние проекта на регулярной основе, проводя мониторинг выполнения работ. В этом пункте необходимо указать структуру и частоту предоставления отчетов. В отчете координатору указываются:

текущие задачи проекта;

• статус их выполнения;

• прогноз сроков завершения для незавершенных задач;

• проблемы проекта и меры по их преодолению.

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

4.8. Как правильно вести проект внедрения системы УУ, или Подводные камни внедрения

Работа над ошибками

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

Ошибки желательно классифицировать по их типам:

1) технические – ошибки системы, когда от нее ожидается один функционал, а реализован другой или этот функционал не работает, хотя он есть в документации;

2) настроечные ошибки – когда в техническом задании описан функционал, а на проверке его нет;

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

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

Почему надо разделять ошибки? Техническое задание на 60–70 % состоит из описания, как система будет работать в принципе, на 30 % – из описания разработок. Если речь идет о разрабатываемых элементах, отличия в ошибках нет; если о работоспособности системы, приходится констатировать неправильную интерпретацию консультантом работы системы при таких настройках. Природа таких ошибок и инцидентов разная. С неработоспособностью системы (все без исключения приложения всегда содержат «баги») разбирается вендор, поэтому на нее довольно сложно повлиять. Ее решение зависит от оперативности работы технической поддержки вендора. Если он не решает их оперативно, значит, надо ждать периода обновления (нового релиза системы), что сказывается на сроке проекта. Ошибки, возникшие по вине консультанта, устраняются самим консультантом.

Ранжирование проблем

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

• критичная для бизнеса;

• критичная для работоспособности системы;

• критичная для работы отдельного участка;

• низкий уровень критичности (интерфейс, алфавитный поиск, неудобства).

Неудобства могут не соответствовать ТЗ, но ошибки все равно не будут высоко критичны. Хотя иногда неудобства выражаются в том, что на работу в системе сотрудник тратит больше времени, чем если бы он это делал в удобном интерфейсе. Время слишком дорого для него и для компании, чтобы не называть данную проблему критичной для деятельности как минимум отдельного участка.

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

Нагрузочное тестирование

Организационные проблемы часто приводят к реальным проблемам. Многие забывают о нагрузочном тестировании – воспроизведении во внедряемой системе (точнее – в программной платформе, которая выбрана для будущей системы) предполагаемого режима работы. Нагрузочное тестирование для любого инженера – превышение стандартной нагрузки.

ПРИМЕР

Настроили учетную систему для молокозавода «Истринский молочный комбинат». Настройка системы осуществлялась в административном корпусе; было проведено нагрузочное тестирование, причем довольно успешное. Но, во-первых, в самый последний момент добавили к классификаторам «забытый» аналитический признак. Во-вторых, начали разворачивать систему не только в административном корпусе, но и на производстве, которое располагалось через дорогу от главного здания. ИТ-департамент решал вопрос, как соединить здания. Первый вариант – радиорелейная связь. Второй – протянуть провод по воздуху. Третий вариант – пустить оптоволокно под землей, чтобы предприятие раз и навсегда было в единой сети. Запускаться надо было срочно, самое дешевое и простое решение – протянуть провод. Но добавленная в последний момент аналитика значительно увеличила объем обрабатываемых данных (любое движение документа сопровождалось вводом нового аналитического признака). Это на 25 % увеличило объем обрабатываемой информации. Таким образом, нагрузочное тестирование, прошедшее до того момента, когда потребовалось связать две эксплуатационные площадки, было де-факто проведено не в соответствии с реальными эксплуатационными условиями функционирования системы. В данной ситуации следовало прокладывать оптоволокно, что не было заложено в проект. В итоге сроки выросли. Чтобы не останавливать работу, заказы вводились в операторском режиме: за день собирался проект заказов и передавался в главное здание, где операторы все вносили вручную.

Часто для нагрузочного тестирования используются программы-роботы, которые имитируют большой объем данных и большое количество документов, вводимых большим количеством пользователей. Если вы – действительно растущая компания, необходимо понять, как ваша система будет вести себя хотя бы в течение трех лет. Три года – жизненный цикл, в течение которого практически полностью обновляется функционал любого бизнес-приложения. Необходимо предположить, сколько пользователей у вас появится за это время. Допустим, вы не мечтаете расшириться до более 2000 человек, но вводите 4000. Аналогичный алгоритм применяем для прогнозирования количества операций: у вас сейчас такой-то оборот, вы планируете его на столько-то увеличить, следовательно, и количество операций увеличится на такую же величину. Результатом может быть не только падение работоспособности, но и ограничение в «железном виде». То есть серверы могут просто не выдержать эксплуатацию в подобном масштабе. В этом случае можно запускаться, но надо помнить, что через год придется докупить дисков, серверов и прочее.

Разделение сред разработки и эксплуатации

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

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

Есть четыре уровня настройки бизнес-приложения:

1) исходное приложение (в поставляемом виде);

2) версия приложения с настроенными классификаторами и опциями;

3) версия приложения с дополнительными разработками;

4) рабочая версия, в которой пользователи работают.

Обычно по мере разработок и развития системы версии три и четыре опережают по богатству функциональности рабочую версию.

Но такой подход применим не ко всем бизнес-приложениям. Многие приложения класса СРМ не подходят для ведения разработок (это конструктор, идеологически не подразумевающий доработки). В подобных ситуациях, например при внедрении системы бюджетного управления и консолидации в ОАО «Связьинвест», мы регламентировали работу пользователей. Поскольку пользователи, вводящие данные, исчислялись сотнями и находились во всех часовых поясах Российской Федерации, у нас был лишь четырехчасовой ночной перерыв, в течение которого можно было заносить в систему новые версии (в другое время это недопустимо). Действия разработчиков должны жестко протоколироваться, потому что проблемы могут быть фатальными: неправильно обновленная система легко уничтожит труд тысячи пользователей за огромный период времени, подорвав доверие к проекту, системе и идее управленческого учета в принципе. Вы платите консультантам не только и не столько за абсолютное знание. Вы платите за те знания, которыми они обзавелись на других проектах. Плюс – за усилия, которые они затрачивают, чтобы разрешить любые проблемы вашего проекта.

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

Проблемы отношений с исполнителем

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

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

Часто смешивают две разные вещи – управление изменениями и управление сроками. В обмен на нерегламентируемые изменения закрывают глаза на сроки. И тогда проект «плывет» на многие годы. Бывают ситуации, когда консультанты на свой страх и риск начинают работы из следующей стадии, в то время как текущая еще не завершена. Но вдруг возникает проблема с приемкой текущих операций. В итоге, все, что консультант сделал «авансом», может «сгореть». Консультанты требуют деньги за работы, выполненные заранее, но формально прежняя стадия еще не завершена и никто никому ничего не должен. Упомянутый здесь подводный камень внедрения называется «панибратское отношение с исполнителем».

ТЗ – как договор

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

Менеджерам проекта необходимо следить за сроками, объемами и бюджетами. Если полностью следовать методологии, проблем возникнуть не должно. Но в реальности чего только не бывает. Сговоры и политические нюансы зачастую играют не последнюю роль. Статистика показывает: 80 % успеха проекта – политические, 20 % – методологические. Политика – это воля, дипломатия и умение добиваться поставленной цели с учетом интересов всех сторон.

ИТ-проект среди других бизнес-проектов

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

Проектные риски

Стороны осознают риски, которые могут возникнуть при реализации проекта, и в связи с этим договариваются о принятии необходимых мер, чтобы предотвратить риски или уменьшить их влияние на проект. Перечень основных рисков и мероприятия по их минимизации представлены в табл. 4.12.

Таблица 4.12. Риски проекта

Ошибки консультанта vs ошибки разработчика

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

Поэтому так важно разделять доработки неработоспособности системы и недоработки консультантов: даже суд встанет на сторону консультанта, если он докажет, что был не в курсе вендорской ошибки, из-за которой общий проект провалился.

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

Это прецедент, но если вы видите, что внедрений покупаемого вами бизнес-приложения в компаниях, близких вашей, не было, вы вправе требовать подобных условий. Потому что вендор не может отвечает за работоспособность своего приложения из-за отсутствия практики внедрения. А она обусловливается не только объемами и отраслью, но иногда и конкретным функционалом. В случае с ритейлером мы столкнулись с нетривиальными требованиями к системе. Наша компания является лидером по автоматизации розничных сетей, но требование у этого потенциального заказчика было такое, что его не могла потянуть ни одна система. Сеть формата DIY отгружала с одного зала и частникам, и оптовикам; причем у оптовиков – явное преимущество в приобретении товара, которое заключалось в следующем. Приезжает оптовик, чей заказ уже оплачен, и требует 10 оконных рам. Их начинают собирать; восемь собрали, а двух нет, потому что они в тележке у частника, который стоит на кассе. Спрашивается: почему нельзя было зарезервировать эти рамы? Потому что зал – общий, склада практически нет. Дальше происходила банальная вещь: по процедуре у частника могли забрать эти две оконные рамы прямо на кассе. Система не может одновременно вести учет для двух видов клиентов, обрабатывать физлиц и оптовиков одновременно. Так был построен бизнес. Основная группа покупателей – строительные бригады. Ради них, если нужно, товар отнимали у простых граждан и возвращали его с кассы в зал.

То есть с точки зрения системы рамы есть, но физически их в торговом зале (на складе) может уже и не быть. Мы предлагали разделить склады для розничных и оптовых покупателей; на последнем можно было бы производить жесткое резервирование. Но это нереально: пришлось бы неоправданно увеличивать уровень запасов для хранения на двух складах. Все магазины DIY работают по такому принципу: нижняя зона для подбора товара, верхняя – для его хранения. Пополнение верхней зоны идет непрерывно. Мы предлагали резервировать товар наверху, а внизу этого не делать. Но клиент возразил, что не может не дать товар оптовику, если он есть на нижних полках, потому что речь идет о приоритетной группе клиентов.

Не было ни одного пункта, по которому мы сошлись с ним во мнениях относительно системы.

Забавный случай

Кассовая система всегда строится по принципу – что бы ни произошло, покупатель должен уйти из магазина с товаром. Если магазин не может выпустить покупателя и принять плату за товар, он выпускает без платы. На практике был такой забавный случай. Открывался один супермаркет и внедрялась его кассовая система. Первичное тестирование прошло отлично. Но одного не учли: запуск был намечен на 29 февраля. Наступает заветный день – торжественное открытие и ни одна касса не может пробить чек! Система просто не поддерживала високосный год. Руководство распорядилось выпустить всех покупателей с товарами бесплатно, и магазин быстро закрыли на инвентаризацию.

4.9. Особенности автоматизации стратегического управления

В разделе 2.1 «Стратегическое управление» мы рассказали о том, как за 14 дней прорваться через блокаду «некогда» и начать у себя внедрение стратегического управления, основанного на ключевых показателях результативности. Это «бумажный старт», у которого нет будущего без использования информационных технологий. Бухгалтерский учет можно вести без ИТ, но не стратегическое управление, ориентированное на требовательных и привыкших к комфорту топ-менеджеров.

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

Обзор продуктов, предназначенных для построения системы стратегического управления (ССУ), достоин отдельной статьи. Главное здесь – понять, что нужно требовать от такого продукта.

Говорю сразу и никогда не устану повторять: продукт, предназначенный для стратегического управления, внедряется и используется не так, как мы привыкли внедрять и использовать ИТ-системы (табл. 4.13).

Таблица 4.13. Сравнение традиционных ИТ-систем и систем стратегического управления[21]

Все тот же Balanced Scorecard

Сила этой популярной методологии не в ее содержимом, а в идее – посмотреть на организацию под разными, заранее определенными, углами зрения. Однако, выискивая во множестве продуктов черты ССП, не забывайте, что продукт должен предоставлять вам не только классические перспективы взгляда на ваше стратегическое дерево, но и произвольные. И конечно, поддерживать другие распространенные методики. Даже если на момент выбора вы считаете себя пожизненным адептом Нортона и Каплана. Например, в качестве объектов планирования можно использовать не Цель, Стратегию, Тактику и Действие из BSC, а Цель, Затраты, Процессы и Результат из «Шесть Сигм».

«Деревья надо знать по именам»[22]

Стратегическая модель – не просто дерево. Его компоненты связаны между собой причинно-следственными связями. Выбираемый продукт может в любой момент времени «разворачивать» это дерево так, чтобы вы эти связи видели (в ССП – стратегические карты).

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

На рис. 4.11 изображен пример любимой многими топ-менеджерами портальной технологии, которая позволяет видеть все ежедневно необходимые показатели деятельности на одном экране и «сверлить» их до глубинных слоев либо выходить на показатели, оказавшие на них влияние. Всем известно типичное желание директора, впервые садящегося за дорогой ноутбук: «Хочу большую красную кнопку!» Если вы про это знаете, почему не требуете от производителя выбираемого продукта?

Рис. 4.11. Удобство портальной технологии

И другие официальные features

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

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

Важной составляющей модели стратегического управления является не просто показатель «План/Факт», но так называемый «Приведенный» факт, показывающий, насколько тот или иной показатель выполняется. Во внимание принимается его абсолютное значение «Объем выработки сопутствующей продукции» и стратегический вес, процент важности для достижения стратегической цели.

Не слушайте заверения поставщиков продукта в гибкости и «широчайших возможностях при создании любых отчетных форм». Во-первых, пользовательские формы ввода = формы отчетности. Вы легко модифицируете их сами: попросите у демонстратора компьютер и попробуйте сделать это прямо на презентации. Во-вторых, набор преднастроенных отчетов показывает, насколько сам производитель «в теме», понимает, для чего он разрабатывает свой продукт. Джентльменским (то есть минимальным) набором готовых к употреблению отчетов ССУ должны стать:

1. План в Виде Диаграммы – с помощью диаграммы показывает «Результат» (были ли достигнуты компанией цели) либо «Продвижение» (насколько хорошо компания выполняет план) для каждого объекта плана.

2. Анализ Результатов – сравнение значений «действия» и результатов.

3. Вклад Подразделений – показывает вклад каждого подразделения в достижение общих целей.

4. Ответственность – отчет демонстрирует объекты плана по ответственным за их выполнение и статус достижения цели.

5. Влияние на План – для выбранных объектов показывает их влияние на общий план.

6. Категория – показывает все объекты плана, сгруппированные по свойствам категории. Например, отчет может воспроизводить формат Balanced Scorecard, который разбивает все объекты на четыре категории: финансы, потребители, внутренние бизнес-процессы, обучение и развитие.

7. Сценарии – сравнивает фактические результаты с несколькими сценариями.

Почем и как у других?

Приготовьтесь к тому, что оплата ПО и услуг консультантов потребует от вас инвестиций, сопоставимых со 100 000 долларов. Если вы решите сэкономить на консультантах, можете потратить эти деньги на стоимость рабочего времени сотрудников, самостоятельно обучающихся новым технологиям: а) информационным и б) управления.

Вот характеристика одного из моих недавних проектов. Компания – многопрофильный строительный холдинг. Команда со стороны заказчика: один «спонсор» (человек, принимающий решения) и три «черных пояса». Мне нравится терминология описания ролей из методологии «Шесть сигм». Так, знатоки бизнеса и новой внедряемой технологии называются «черными поясами». Вместе с нашими консультантами (один-два человека) они составляют рабочую группу. Те, кому они несут свои знания для конкретного использования системы, именуются «зелеными поясами».

С такой командой мы в течение 36 календарных дней создавали модель стратегического управления, состоящую из 76 показателей, расположенных в четырех «измерениях» – углах зрения. Система охватывала 13 департаментов компании. В итоге, всем стало очевидно, что дороги назад нет, системе – быть! А как ее развивать – понятно ВСЕМ.

Вот и все – для начала работы над внедрением в вашей компании технологий стратегического управления. Только не забудьте, что «стратегический план не приносит никакой новой информации, сам по себе он ничему вас не учит. Стратегия бездействует и только прикидывается всезнающей, в то время как тактика постоянно проходит испытание рынком»[23].

4.10. Современные тенденции развития ПО для бизнеса

Вы спросили меня о возможностях «ПО по запросу».

Да хватит уже говорить об этом – его просто нужно использовать.

Марк Бениофф

Основные понятия

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

Собственническое или проприетарное программное обеспечение (англ. proprietary software) – это несвободное программное обеспечение, не удовлетворяющее критериям свободы ПО. Правообладатель сохраняет за собой монополию на его использование, копирование и модификацию, полностью или в существенных моментах.

Не следует путать с собственническим коммерческим программным обеспечением, которое может быть свободным.

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

Свободное программное обеспечение – программное обеспечение, в отношении которого пользователь обладает «четырьмя свободами»: запускать, изучать, распространять и улучшать программу (см. ниже).

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

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

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

Подавляющее большинство открытых программ является одновременно свободными и наоборот, поскольку определения открытого и свободного программного обеспечения близки.

Только удовлетворяющая всем принципам свободы программа может считаться свободной, то есть гарантированно открытой и доступной обществу. Нужно подчеркнуть, что эти принципы оговаривают доступность программ для всеобщего использования, критики и улучшения, но не связанные с их распространением денежные отношения, в том числе не предполагают бесплатность. В англоязычных текстах возникают разночтения, поскольку слово «free» по-английски означает не только «свободное», но и «бесплатное» и нередко употребляется по отношению к бесплатному программному обеспечению, которое распространяется без взимания платы за использование. При этом оно недоступно для изменения сообществом, потому что его исходные тексты не опубликованы. Такое бесплатное ПО вовсе не является свободным. Наоборот, свободное ПО вполне можно распространять (и распространяют), взимая плату и одновременно соблюдая критерии свободы: каждому пользователю предоставляется право получить исходные тексты программ, изменять их и распространять далее. Всякое программное обеспечение, пользователям которого данное право не предоставляется, является несвободным – независимо от любых других условий.

Во избежание путаницы повторим уже сказанное в «зеркальном» виде: противоположностью свободного программного обеспечения является собственническое (проприетарное) ПО, которое тоже может быть как коммерческим, так и бесплатным (freeware).

SourceForge.net – один из самых больших в мире каталогов открытого программного обеспечения, значительная часть которого распространяется и как freeware.

Дадим определение «ПО по запросу» и «ПО как услуга».

On-demand – [ПО по требованию] термин, обозначающий программное обеспечение, распространяющееся на условиях аренды. Это ПО, размещенное на серверах производителя с возможностью удаленного доступа (обычно через Интернет, с помощью веб-браузера). После подписки на услугу клиент получает возможность использовать ПО в течение оговоренного периода времени.

Данную модель распространения ПО начали использовать в западных странах в 1997–1998 годах. Доля ПО, распространяемого на условиях аренды, постоянно растет. Такую модель продаж активно используют производители бизнес-систем. В первую очередь, CRM-систем и систем управления проектами, поскольку данная модель доступа к ПО позволяет контролировать территориально распределенных продавцов, консультантов и агентов без каких-либо затрат на организацию единого рабочего пространства.

Серьезным преимуществом on-demand-систем является отсутствие ИТ-затрат. Так как система находится на стороне поставщика услуг, все работы, связанные с поддержкой оборудования и программного обеспечения в рабочем состоянии, выполняет поставщик услуг. Исчезают и затраты на серверное оборудование, сопутствующее программное обеспечение. Одним из факторов, значительно снижающих затраты на сопровождение, является автоматическое бесплатное обновление on-demand-систем. А ежегодные затраты на обновление версий обычных систем составляют в среднем не менее 15–40 % от их стоимости.

Как правило, on-demand-системы размещаются в крупных дата-центрах. В этом случае также начинают работать механизмы защиты данных самих дата-центров, значительно более серьезные, чем те, которые может себе позволить средняя компания. В случае размещения on-demand-системы в дата-центре обеспечивается лучшая непрерывность работы (достигает 99–99,8 % времени). Также крупные дата-центры дают гарантии на сроки замены вышедшего из строя оборудования.

В целом on-demand – это комплексная услуга, включающая как возможность использования ПО, так и все сопутствующие услуги по поддержке его работоспособности.

Software as a service (SaaS) – программное обеспечение как услуга – модель предложения программного обеспечения потребителю, при которой поставщик разрабатывает веб-приложение, размещает его и управляет им (самостоятельно либо через третьих лиц) с целью и возможностью использования заказчиками через Интернет. Заказчики платят не за владение программным обеспечением как таковым, а за его использование (через API, доступный через веб и часто использующий веб-службы). Близким к термину SaaS является on-demand (приложение по запросу).

Принципиальным отличием модели SaaS от более ранних (hosted applications и application service provider (ASP)) является то, что приобретается именно услуга и интерфейс (пользовательский или программный), то есть некоторая функциональность без жесткой привязки к способу ее реализации.

В модели SaaS:

– приложение приспособлено для удаленного использования;

– одним приложением пользуется несколько клиентов (приложение коммунально);

– оплата взимается как ежемесячная абонентская плата или на основе объема транзакций;

– поддержка приложения входит в состав оплаты;

– модернизация приложения происходит плавно и прозрачно для клиентов.

Проприетарное vs свободное ПО

Описание, плюсы и минусы

Поддержка. Разница в поддержке проприетарного и свободного ПО существенна, свободное ПО в этом плане выигрывает.

В случае с поддержкой проприетарного ПО вы фактически платите за исправление багов разработчиков. А когда речь идет о сопровождении свободного ПО, вы действительно платите за его развитие. Обладая исходным кодом, вы можете самостоятельно исправлять все мелкие баги. Это гораздо проще и быстрее, чем писать письмо в службу сервисной поддержки, которая присвоит вашему запросу определенный код, и вы днями и ночами будете следить за статусом исполнения вашей проблемы. Потом получите нерадостное сообщение: «Да, действительно, это ошибка! Мы ее исправим в следующем релизе, который выйдет через три месяца/в следующем году». С подобной картиной сталкивались многие.

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

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

К тому же, свободное ПО подразумевает сообщество, community. Например, adaptive planning предлагает два уровня поддержки своих программных продуктов. Первый, бесплатный – собственно поддержка через сообщество: пользователь может задать вопрос разработчикам бесплатной версии или на интернет-форуме. Им это действительно интересно – это их детище. Начинаются споры и обсуждения, которые часто приводят к улучшению продукта и устранению его недостатков.

Основные поставщики «Свободного ПО»

Основанные на технологиях с открытым исходным кодом, современные BI-инструменты оказываются совместимы с Linux, Apache, JBoss, а также с Perl, Python, Ruby, MySQL, PostgreSQL и т. д. Глобальная совместимость позволяет фактически любому ИТ-департаменту любой компании применять BI-инструменты с открытым исходным кодом. Понимая это, многие производители ПО и оборудования запустили инвестиционные проекты, цель которых – создать простые, состоящие из множества модулей BI-инструменты с открытым исходным кодом при минимальной стоимости рабочего места. Это, в свою очередь, заставило малый и средний бизнес обратить внимание на рынок BI, ранее для него закрытый из-за высоких издержек.

Mondrian – сервер с открытым исходным кодом, написанный на языке Java. Поддерживает язык запросов MDX (многомерные выражения) и спецификации XML for Analysis и JOLAP. Mondrian может использовать различные источники данных (в том числе и SQL), умеет кешировать в памяти суммарные результаты.

Ingres – коммерчески поддерживаемая открытая реляционная база данных. В начале 1970-х годов была создана как научно-исследовательский проект в Университете Калифорнии (США). Оригинальный код Ingres был доступен за минимальную плату под версией лицензии BSD. С тех пор, начиная с середины 1980-х годов, Ingres породил множество коммерческих баз данных, включая Sybase, Microsoft SQL Server, NonStop SQL и множество других. Ingres – один из наиболее влиятельных современных компьютерных научно-исследовательских проектов.

Своим появлением система с открытым исходным кодом JBoss перевернула рынок серверных приложений, вынуждая традиционных вендоров полностью менять свою продуктовую стратегию (пример – компания BEA*) либо создавать альянсы по продвижению своих брендов (пример – альянс IBM и Oracle)**. Этот подход существенно снижает затраты на маркетинг и продажи, тем самым способствуя перераспределению бюджетов в пользу исследования и разработки новых продуктов.

Вот далеко не полный перечень «свободных» продуктов:

Ubuntu Server & Desktop Edition;

• Alfresco ECM & WCM;

• Zimbra CS;

• Sugar CRM;

• Linux;

• Palo-Server;

• Spago BI.

«ПО как услуга»

Описание, плюсы и минусы

Признаки ПО «по запросу»:

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

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

3. Оплата основывается на подписке (например, из расчета на одного пользователя или за ежемесячную плату) или на степени востребованности приложения (скажем, на числе выполненных за определенный период транзакций). Если предусмотрена покупка лицензий, это не on-demand и не SaaS.

Сектор SaaS-провайдеров сейчас бурно растет, и многие компании, которые предоставляют данный сервис, уже вышли на биржу. Котировки компаний такого класса всегда росли быстрее рынка и NASDAQ. Это достаточно красноречивое доказательство того, что сектор SaaS действительно развивается. Ниже приведены преимущество SaaS для клиентов, поставщиков ПО и инвесторов.

Таблица 4.14. Преимущества модели SaaS

Слабым местом Software As A Service является контроль нескольких сервис-провайдеров, выстраивание интеграции данных из двух разных задач. Может показаться, что проще обратиться к традиционной методике введения, построения информационно-системных компаний, чем заниматься «лоскутной» автоматизацией.

На самом деле это не так. Компании, предоставляющие услуги в данной области, выбирают нишевые задачи, которые не нуждаются в тесной интеграции с другими задачами, как, например: расчет заработной платы, включая кадровую систему; управление обучением сотрудников; бюджетное управление. В большинстве фирм одним из компонентов бюджетного управления является бюджетное планирование на основании имеющихся данных за прошлые периоды. Оно хорошо укладывается в идеологию Software As A Services и не нуждается в ежедневной и точной интеграции с другими приложениями. Если необходим факт, то его достаточно выгрузить из системы и сохранить; нужен план – следует та же процедура. Локальные задачи легко решаются посредством сервисов, а глобальные, связанные с охватом компании в целом и поддержкой информационных ресурсов, – с помощью серьезных ERP-приложений.

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

Microsoft уже предлагает свой Dynamics CRM в режиме хостинга приложений. Серьезным конкурентом выглядит RightNow Technologies – после покупки SalesNet с ее ПО, предназначенным для поставки услуг на основе Web.

СЕГОДНЯШНИЙ ДЕНЬ КОМПАНИИ SALESFORCE

Сегодня Salesforce вполне успешна. В середине января текущего года СЕО компании Марк Бениофф (Marc Benioff) сообщил о подписании контракта с Dell, согласно которому в ней будет организовано 15 000 рабочих мест с приложениями, распространяемыми по подписке.

Это немаловажное событие в жизни быстро растущей Salesforce. Общепризнано, что ее CRM-пакет проще в применении для непосредственных исполнителей, чем традиционные клиент-серверные

CRM-приложения. Теперь Dell стала вторым после Cisco по-настоящему крупным клиентом Salesforce.

На специальной конференции, посвященной заключению соглашения с Dell, Марк Бениофф сказал: «С нами успешно работает множество SMB-компаний, общее число пользователей – 556 000, и я не вижу особых проблем добавить к ним еще 15 000».

Общий доход Salesforce только за IV квартал 2006 года вырос на 57 %. Согласно прогнозам Уоллстрит, последний финансовый год, который у компании закончился 31 января, принесет ей без малого полмиллиарда долларов. Обнародованы и планы на 2008 финансовый год – от 710 до 720 млн долларов. Если все пойдет так, как планирует руководство Salesforce, 2010 год должен принести ей звание миллиардной компании.

Примеры «ПО как услуга» – Adaptive Planning

Excel – это сервис для работы с электронными таблицами, но при ведении бюджетирования необходимо работать с многомерной, финансовой моделью предприятия в многопользовательском режиме с единой версией факта. Adaptive Planning сумела сделать такой продукт, который действительно легок в функциональном смысле и в процессе внедрения.

Вся идеология компании Adaptive Planning нацелена на то, чтобы дать предприятиям среднего бизнеса простой в использовании и, что еще важнее, – во внедрении продукт бюджетного управления.

Рис. 4.12. Пример экрана Adaptive Planning

Большим преимуществом Adaptive Planning является то, что в его состав входят так называемые мастера создания моделей (рис. 4.12). Мастер расскажет, что такое измерения, финансовая структура, предоставит уже предзаполненные формы ввода и т. п. Вы можете получить рекомендацию, как лучше сделать план счетов (статьи доходов и затрат) с учетом того, какие статьи доходов и затрат обычно используются другими фирмами. Вам остается буквально «расставить галочки». Моя компания уже около 10 лет продает проприетарные системы и обучает пользователей с ними работать. Люди платят деньги, приходят, садятся за парты, и мы рассказываем, что такое измерение и т. д. Полдня на это уходит точно, вместо того чтобы человек просто получил доступ к системе on-demand, прошел необходимую процедуру и сам создал первую в жизни бюджетную модель.

Пример «свободного ПО» – Palo Server

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

Миссия Jedox – сделать Excel лучше. Тому, кто работает в финансовой сфере, не может не нравиться Excel. Jedox предлагает бесплатно скачать продукт под названием Palo-Server.

Кстати, если прочитать обратно слово «Palo», получится «Olap», что звучит как английское «all up». – Еще «palo» по-испански «дерево». И с такой аналогией я бы согласился, потому что финансовая модель – это фактически дерево. Одно из значений словосочетания «all up» – как раз «дерево». Многомерное дерево, в котором любой отдельно взятый элемент может сочетаться со всеми остальными. При описании структуры финансовой модели используются такие термины, как «leaf item» (дословно – «листовой элемент»), то есть последний элемент, не являющийся веткой для других элементов.

Скачивание и установка системы Palo занимает несколько минут. Далее вы открываете привычный для вас Excel через ярлычок Palo Excel Add in (прим.: интересна разница между «add-on» и «add-in». Add-on – это фактически новое приложение, выстроенное над основной программой; add-in – функциональное «встраивание» в основную программу, в данном случае – платформу, под названием Excel. Говоря иначе, это улучшение основной платформенной программы).

Открыв таким образом Excel, вы заметите, что у вас появился еще один пункт меню верхнего уровня. В этом пункте пользователь может создать, например, модель или отчет.

Плюсы такого приложения понятны и очевидны:

• вы по-прежнему работаете в Excel;

• ваша система – многопользовательская;

• все данные хранятся в единой базе;

• вам больше не придется заниматься кропотливым «сведением» десятков и сотен электронных таблиц в единую отчетную таблицу.

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

Поэтому сегодня продукт Palo Server (компания Jedox) по нескольку раз в день скачивают и устанавливают пользователи всех стран мира.

Тема open source сейчас настолько модная, что люди в погоне за трендом готовы объявить ее чуть ли не полной заменой всему, что было наработано ранее. Свою роль здесь сыграли идеологические факторы, проблема вен-дорозависимости и просто реклама. В будущем бизнес станет развиваться, используя и свободное, и проприетарное ПО. Понятия вытеснения и конкурентной борьбы просто исчезнут. Если и будет борьба, то не на уничтожение, а на сосуществование.

Многие производители проприетарного ПО используют сегодня популярность свободного ПО, чтобы легко и незатратно продвигать самих себя. Идея проста: во всемирную сеть выкладывается урезанная версия продукта, обладающая функциями, которые позволили бы поверить в то, что цельный продукт действительно достоин внимания. Я бы разграничил реальные open source бизнес-приложения и такие «приманки» для клиентов. Настоящее open source решение – это, например, SpagoBI, Pentaho, которые мало того что разрабатываются в режиме открытого ПО, так еще используют его разные компоненты и платформы.

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

По поводу open source… Кто же все-таки победит – проприетарные или свободные? Мне кажется, что с точки зрения бизнеса подобная батальная лирика роли не играет. Гораздо важнее интересы дела. Это противопоставление искусственно, пока open source разработки не могут покрыть с достаточной долей надежности такой массив процессов организаций, какой обеспечивают традиционные системы. Оpen source зачастую имеет конкурентное преимущество лишь за счет своей бесплатности.

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

Если взять любую из линеек бизнес-приложений (мы их назвали «слоями регулярного менеджмента»), для каждой из них найдется и традиционное, и свободное ПО, и ПО «как услуга»:

• бюджетирование;

• управление финансами;

• CRM;

• управление логистикой;

• управление производством;

• управление персоналом;

• управление неструктурированными данными;

• управление электронным коммерческим документооборотом.

Я не исключаю, что проприетарное ПО в будущем формально станет свободным[24] – прецеденты уже есть. Microsoft давно действует по такому принципу, закрывая глаза на пиратские копии своего софта и открывая части ОС Windows для государственных и учебных учреждений.

Главное, чтобы создатели традиционного ПО поняли ценность сервиса, а не хватались только за продажу лицензий. Чем больше будет появляться свободных производителей с хорошей поддержкой, тем быстрее упадут цены на проприетарное ПО, на лицензионную составляющую его стоимости.

Основные поставщики ПО «по запросу»

Adaptive Planning – лидер в области поставки системы бюджетного управления в виде услуги. Более 550 клиентов по всему миру. С середины 2009 года представлен и в РФ.

Blackboard – ведущий поставщик приложений и услуг для дистанционного обучения. Компания предлагает пять приложений, объединенных в два предложения – Blackboard Academic Suite и the Blackboard Commerce Suite. Клиентами компании являются общеобразовательные и высшие учебные заведения, корпорации, государственные органы, издательства и ориентированные на студентов торговые организации.

Concur Technologies – ведущий поставщик on-demand – бизнес-приложения по автоматизации управления кадрами.

DealerTrack – ведущий поставщик приложений и аналитических решений для розничной торговли. Сеть активных контактов состоит из более чем 22 000 дилеров и более 375 финансовых ресурсов.

j2 Global Communications берет на аутсорсинг услуги по обмену сообщениями с дополнительными функциями и коммуникациями для индивидуальных клиентов и компаний любых размеров по всему миру. Компания обеспечивает факс, голосовую почту, электронную почту и телефонную сеть с помощью глобального телефонного/интернет-протокола, который охватывает более 2000 городов в 35 странах на пяти континентах. У компании более 9000 подписчиков.

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

LivePerson – ведущий поставщик решений для он-лайн общения и технологий поддержки пользователей. Приложения компании обеспечивают продажи в режиме реального времени, маркетинг и поддержку клиентов, позволяя безопасно общаться с интернет-пользователями. Решения LivePerson (проактивный чат, проактивные услуги, «кликнуть, чтобы позвонить», онлайн-ознакомление с данными, маркетинг в режиме реального времени) помогают клиентам увеличивать продажи, снижать издержки по обслуживанию клиентов и ускоряют реакцию на их запросы. У компании более 4000 внедрений, включая 200 предприятий-клиентов.

Omniture – ведущий производитель онлайн-решений по оптимизации бизнеса. Предлагает гибкий и легкий инструмент с онлайн многоканальными и оффлайн бизнес-инициативами без существенных инвестиций в ИТ-инфраструктуру. У компании более 2500 клиентов.

RightNow Technologies предлагает технологии по сокращению операционных издержек во взаимоотношениях с клиентами: услуги по автоматизации веб-самообслуживания, голосового самообслуживания, обратной связи, аналитики, торгового персонала и маркетинга. У компании более 1800 клиентов по всему миру.

Salary.com предлагает решение по управлению зарплатой, которое позволяет выбрать оптимальное соотношение оплаты и эффективности и помогает привлечь, мотивировать, наградить и удержать лучших работников. У компании более 7000 подписчиков.

Salesforce.com – мировой лидер в сфере предоставления услуг по управлению взаимоотношениями с клиентами, акцентирующий внимание на автоматизации торгового персонала. У компании 32 300 клиентов по всему миру.

Taleo предлагает решение по рекрутингу, развитию, оплате, удержанию и приему на работу высококвалифицированного персонала. База компании включает 1000 клиентов и 900 000 пользователей.

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

5. Развитие УУ

5.1. Как рассчитать совокупную стоимость владения системой УУ

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

• на консалтинг;

• на лицензии;

• на обучение персонала;

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

• на сопровождение системы.

Сопровождение системы, как правило, включает два компонента: подписку на обновления системы и сопровождение консалтинговой фирмой, которая в договорах прописывает его рамки. Вероятно, это будет выделенный Helpdesk или обращения по электронной почте. В любом случае вы сами должны принять решение – насколько вам необходима сторонняя помощь при эксплуатации системы. Подписка на обновления часто включает не просто изменения стандартного функционала и исправления неработающего, но и доработки, связанные с изменением законодательства в стране. Это, по большей части, касается бухгалтерского функционала, хотя такие фундаментальные изменения в учете, как необходимость прописать тот же номер ГТД[25] во всех документах, в свое время привели к кардинальному изменению всех существующих в России ERP-систем. Но такое бывает редко, поэтому уровень абонентской платы необходимо выбирать самостоятельно. Главное – сопоставить все элементы затрат на систему. Неправильно говорить, что система стоит 5 млн долларов лишь потому, что консалтинг и лицензии вместе образуют такую сумму. ТСО имеет гораздо больше параметров. По истечении жизненного цикла системы (практически для любой системы равен трем годам, а для систем типа SAP – четыре-пять лет) вам придется задуматься о новой системе либо о новых, небольших системах, которые бы функционировали параллельно с большой.

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

Это очень полезная цифра. Благодаря ей вы сможете оценить, были ли у вас ранее настолько масштабные проекты. Например, мы сотрудничали с компанией, которая занимается бурением скважин. Когда мы вместе просчитали полную совокупную стоимость владения системой (по вышеуказанной схеме), они сказали: «По стоимости проект равносилен строительству новой скважины…» и задумались: а стоит ли? Из скважины так или иначе нефть пойдет, а даст ли результат внедренная система, не предугадаешь. Я не утверждаю, что сравнение цены скважины и системы – неправильный элемент анализа. Управленец вообще вправе сравнивать, что он хочет и с чем хочет, хоть со стоимостью своего коттеджа или автомобиля. Все зависит от того, какими ценностями он оперирует, как ему легче воспринять ту или иную сумму. Ведь в абсолютном эквиваленте 5 млн долларов – внушительная сумма. Предприятию, оборот которого даже полмиллиарда, эта цифра может показаться большой. Но если это предприятие собирается на следующий год увеличить оборот до миллиарда, то без систематизации всех бизнес-процессов оно не сможет этого сделать. Придется идти на столь мощные инвестиции.

Еще проект внедрения можно сравнить с инвестиционным проектом. Сопоставимы ли затраты на него с остальными типами инвестиционных проектов в вашей компании? Сравнивать надо не только с вашими привычными инвестиционными затратами, но и с тем эффектом, который вы ожидаете от этих проектов. Если за 5 млн построить новый цех, то с его помощью можно увеличить производство – вроде, эффект очевиден, а при внедрении системы эффект от вложенных средств неосязаем. Здесь мы касаемся очень скользкой темы – возврата инвестиций от внедрения информационной системы. Среди консультантов и продавцов программного обеспечения действует негласное правило: компания психологически не может потратить на оптимизацию управленческого учета больше одного процента от своего оборота. Приведу очень интересный пример, как один наш клиент при обороте, условно говоря, 150 млн, решился на автоматизацию, совокупная стоимость владения которой только по прямым затратам составляла около 3 млн (по идее должно было быть 1,5). Интрига заключалась в том, что на следующий год его оборот стал 500, а еще через год – 700 млн. Управленец этой компании (речь идет о крупном дистрибьюторе) просто хорошо осознавал свой рост; понимал, сколько внедрение стоит сегодня и сколько будет стоить завтра, и удачно выбрал момент для нормализации бизнес-процессов, потому что такой проект – это в конечном итоге изменение культуры и получение выгоды.

Затраты на проект. Их тьма

У нас существует теория трех видов затрат:

1. Прямые.

2. Косвенные.

3. Менеджерские затраты (самый сложный, но очень интересный вид).

Косвенными считаются затраты времени вашего персонала на внедрение. Прямые затраты на обучение – это зарплата учителю, а косвенные затраты на обучение – это зарплата, которую вы платите сотруднику, пока он учится. Конечно, вы можете возразить, что это несущественно – обучение становится его должностными обязанностями, – но в большинстве случаев с сотрудников, которые занимаются проектами, их текущие обязанности не снимаются. Если человек был загружен на 100 %, с появлением системы – на 150–200 %, то есть люди сидят вечерами, работают в выходные и т. д. Если вы им за это платите повременно, затраты становятся косвенными. Еще нужно учесть бонусы. Многие считают, что бонусы, заложенные в бюджет проекта, являются косвенными затратами. Но это самые что ни на есть прямые затраты на проект; оплата командировочных, связанных непосредственно с проектом, тоже относится к прямым затратам. Сотрудник занимает рабочее место и площадь, косвенные затраты по отношению к оплате его труда автоматически становятся косвенными затратами проекта.

Есть еще затраты, вызванные организационными изменениями. Любые перестановки чреваты снижением эффективности труда. Дело в том, что внедрение оперативной части управленческого учета в 90 % случаев не является жизнеобеспечивающим. Непосредственно у бизнеса нет потребности в новой системе управленческого учета. Это не автоматизация, например, складских операций или производства, когда процесс шел медленно из-за отсутствия автоматического планирования заказов. А внедрение ERP-системы в части производства положительно отразилось на эффективности, заказы стали обрабатываться быстрее, и этот эффект можно посчитать. Автоматизация управленческого учета – ненасущная задача, нужная управленцу, потому что его не устраивает процесс поступления к нему информации. Исполнители не заметят улучшения своих условий труда, скорее, наоборот. В 90 % случаев происходит ухудшение условий труда, потому что, во-первых, нужно научиться работать в новой системе, и, во-вторых, работать в ней, скорее всего, будет неудобно, потому что usability практически никогда не является целью проекта. Самые эффективные внедрения, самые быстрые и законченные, совершаются на системе с минимальными настройками, а уже потом начинаются мини-проекты по улучшению дружелюбности интерфейсов и т. д. Поэтому объективно возникают косвенные затраты, связанные с переходом на новую систему или на новую организационную структуру. Переходы чреваты задержками в работе, а это стоит денег.

Прямыми являются затраты на аппаратное и инфраструктурное обеспечение. Прокладка новой сети, новых каналов – тоже прямые затраты на проект. Правда, иногда инфраструктурные затраты экономически нецелесообразно относить полностью на проект, потому что их благами пользуются даже те, кто в нем не участвуют. Прокладка оптоволоконного кабеля для всей компании не будет относиться исключительно к затратам проекта, хотя будет его непременным условием. Поэтому справедливо разнести такие затраты пропорционально – взять от стоимости прокладки оптоволокна отношение реальных пользователей системы к пользователям оптоволокна. Еще есть щепетильная тема лицензирования базового программного обеспечения (Windows, Office и т. п.). Ведь зачастую на предприятиях число компьютеров растет быстрее, чем количество лицензий на базовое программное обеспечение. В итоге внедрение большой системы сопровождается тотальным лицензированием. Здесь точно так же нельзя всю стоимость базового лицензирования объявлять прямыми затратами.

A теперь о так называемых «менеджерских затратах». Например, вы управляете большой компанией, занимаетесь продажей мобильных телефонов, у вас начинается проект по автоматизации, и это совершенно новый проект. Вы, как управленец, отвлекаете часть своего собственного ресурса на то, чтобы внедрить у себя систему. Вместо того, чтобы развивать бизнес, идти вперед, заключать новые соглашения, вы занимаетесь несвойственной вам задачей, которая вам интересна как некий элемент инвентаризации ресурсов, – остановиться и посмотреть, «а что же у меня есть», встряхнуть организацию, найти возможных потенциальных лидеров (в проектах внедрения на первый план как раз выступают не начальники отделов, а их заместители или просто способные люди). Но несмотря на полезность проекта, вы можете прикинуть, сколько потеряете, не занимаясь основным бизнесом, а отвлекаясь на проект, – это те самые затраты третьего уровня. То же самое происходит при сопровождении внедренной системы. Создание HelpDesk – тоже несвойственная бизнесу функция, которая находится в подчинении департамента ИТ, а департамент ИТ выполняет множество других обязанностей. В итоге директор этого департамента подчиняется финансовому либо напрямую генеральному директору, и вся цепочка занимается несвойственными им прежде функциями. Это похоже на эффект энтропии, когда маленькая посторонняя деталь обрастает еще большими несвойственными для организации в целом вещами. Любой прецедент всегда существует по принципу снежного кома.

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

Возврат инвестиций

Чтобы получить представление, где играет роль эффективность, необходимо научиться ставить перед собой следующие вопросы. Каков денежный эквивалент знания о тенденциях изменения рыночных условий, если они меняются чаще, чем один раз в месяц? Сколько стоит информация, которую вы не получаете даже после внедрения системы управления ресурсами предприятия (ERP), CRMсистемы и системы управления логистическими цепочками (Supply Chain Management, SCM)? Современная деловая литература и опыт подсказывают, что можно выделить, как минимум, шесть источников повышения корпоративной эффективности – шесть выгод внедрении CPM[26]-систем:

1. Увеличение деловой подвижности. Чем раньше будет получена достоверная информация, тем больше будет выбор.

2. Улучшение процесса планирования. Доступ ко всему массиву информации по заданной теме улучшает процесс планирования.

3. Улучшение процесса принятия решений. Этот процесс можно представить как вовремя доставленную информацию. Где производство построено на удовлетворении нужд сегодняшнего дня, там необходима и информация такого же качества.

4. Прибыль от фондового рынка. Рынки вознаграждают компании, которые пристально следят за своими деловыми операциями. Акционеры вознаграждают те компании, которые оправдывают их ожидания.

5. Улучшение корпоративной организации. Чем шире распространяются корпоративные знания, тем совершеннее становится организация. Пропаганда значения и понимания индивидуальных задач среди сотрудников существенным образом повышает уровень корпоративной организованности. Термин для такого преимущества – «прибыль от управляемости» (return on management, ROM).

6. Объединение организации. Когда CPM-система используется для привязки стратегии к тактике и измеримым результатам, организация начинает действовать слаженно – каждый работает на общие цели.

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

ПОДСЧЕТ ЭФФЕКТИВНОСТИ (И ДРУГИХ НЕМАТЕРИАЛЬНЫХ ВЫГОД)

Каждому было бы интересно подсчитать доходы от эффективности при использовании CPM-систем. Вопрос заключается в том, как это сделать. Ответ совсем не так очевиден. Данный раздел описывает четыре методики выражения в числовом эквиваленте нематериальных выгод. Это предполагаемая сумма прибыли, средняя ожидаемая сумма прибыли, прибыли от ERP (управления ресурсами предприятия) и конкурентное преимущество.

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

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

Например, организация инвестировала 300 000 долларов в создание системы управления продажами, и она сокращает процесс составления отчета с двух недель до режима реального времени. Такая система управления сэкономила две недели. Условная сумма прибыли от более быстрого доступа к информации оценивается в 150 000 долларов в неделю или 300 000 за две недели.

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

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

Таблица 5.1. Программа CPM для бюджетирования

Получение прибыли от управления ресурсами предприятия. Любая компания, вложившая деньги в систему управления ресурсами предприятия, имеет по-настоящему детальную информацию для этого проекта. Цель – вернуться к этой информации и определить, какие ожидавшиеся прибыли от проекта не были реализованы. Областями, где обнаруживается максимальное количество нереализованных прибылей, обычно являются информационная интеграция, составление отчетов и анализ. Несмотря на обещание ERP создать единое интегрированное хранилище данных, многие организации вынуждены сохранить некоторые ранние системы и отдельные программы. Сила CPM-систем заключается в том, что они позволяют объединить вместе в корне различные источники данных и улучшают (если не предоставляют впервые эту возможность) процесс запроса данных и возможности по созданию отчетов при применении ERP. Поэтому новые CPM-системы могут быть изначально наделены этими уже признанными и подсчитанными прибылями. Как и вычисление суммы ожидаемой прибыли, ERP-методики получения прибыли являются оправданным и консервативным методом подсчета, установленным корпоративной политикой и практикой независимо от начинаемого проекта.

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

Превратить расчет отдачи от инвестиций в конкурентное преимущество непросто, если смотреть на такие вещи, как веб-сайты клиентов или на программы по управлению взаимоотношениями с клиентами. Необходимо выразить лояльность покупателя, увеличение доли рынка, улучшение процесса принятия решений и тому подобное в числовом эквиваленте. Во многих случаях даже компании, проводившие серьезные деловые исследования, смогли найти материальные выгоды для покрытия только 40–80 % предполагаемых расходов на проект[27]. Если те нематериальные выгоды так хороши, чтобы оправдать оставшиеся миллионы, вложенные в ERP, они, безусловно, должны быть проанализированы CPM-системами.

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

Основная стратегическая выгода внедрения CPM-систем заключается в том, что они объединяют организацию вокруг стратегического видения. Работа, посвященная ROI и бизнес-исследованиям, среди управленцев высшего звена является началом достижения этой выгоды.

Сразу оговоримся: управленческая система не нацелена на улучшение условий труда (условия труда улучшатся, но в процессе эксплуатации, когда люди поймут эффект работы в едином информационном пространстве).

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

Любой фактор, влияющий на эффективность, сразу обрастает несколькими субфакторами. Есть показатель «скорость обработки заказа»: раньше она составляла час, теперь – 15 мин. От этого есть прямой и косвенный эффекты. Прямой эффект – как минимум, увеличение зарплаты человека, занимающегося обработкой этих заказов (раньше он мог в день делать восемь заказов, теперь – 32). От него выстраивается цепочка косвенных воздействий: большее количество заказчиков можно привлечь в единицу времени, увеличивается лояльность заказчиков и т. д. Остается найти все измеряемые факторы и провести от них как можно больше таких «веточек». Это называется деревом стоимостных факторов. Даже когда «веточка» не исчисляется напрямую (например, если речь идет об измерении лояльности одного заказчика), эти пустые места заполняются экспертно: мы обращаемся непосредственно к директору по продажам: «Сколько стоит лояльность одного клиента?» Лояльный клиент – тот, кто продолжает делать заказы. Если он делает новые заказы, по объемам сопоставимые с заказами от новых клиентов, в эту графу можно запросто поставить сумму, затрачиваемую на продажи и поиск новых клиентов. Таким образом, лояльность тоже исчисляется деньгами. То же самое с лояльностью персонала: если ему удобно и приятно работать и он видит, что, используя эту систему, повышает свою компетенцию и ценность, это тоже чего-то стоит – затрат на поиск и обучение новых сотрудников (а также затрат на неизбежное в случае замены персонала падение эффективности).

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

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

Б. Рябов: «Мы росли на несколько десятков процентов в год; быстрый рост остановился только в середине 2007 года. В какой-то момент стало очевидно, что компания становится неуправляемой, а это разрушает смысл новых приобретений. Экономический смысл внедрения не сводится к подсчету цифр. Будь у нас такая история: есть хорошо работающая и стабильная фирма, давайте что-нибудь с ней сделаем? внедрим систему и посчитаем выхлоп? Нет, нам ближе другой пример. Человек едет на велосипеде, у него осталось три часа, а проехать надо еще 200 км. Он понимает, что на велосипеде эту дистанцию не преодолеть. Но с велосипеда слезть не может – это будет стоить ему времени. Так он по дороге будет придумывать и собирать двигатель, пытаться ускорить свой велосипед».

5.2. Теория жизненного цикла систем

Жизненный цикл (ЖЦ) системы в общем смысле – это процесс создания, разработки, эксплуатации, поддержки и снятия с эксплуатации системы управления. Методика построения стадий жизненного цикла системы зависит от его концепции, то есть от модели.

Наиболее подходящие модели ЖЦ в зависимости от типа бизнес-приложения: Каскадная (рис. 5.1)

Каскадная модель ЖЦ используется, когда практически все исходные условия проекта известны: требуемая функциональность (приложение готово, существует, его «просто» нужно настроить под конкретное предприятие), временные рамки и «география» внедрения (одна площадка или их перечень и характеристика известны не может).

Применяется при внедрении приложений класса ERP, CRM, CPM, любых комплексных многофункциональных бизнес-приложений.

Рис. 5.1. Схема каскадной концепции ЖЦ

Инкрементная (рис. 5.2)

В инкрементной модели требования разрабатываются изначально – один раз для всех очередей («конструкций») системы. Затем система вводится по очередям; каждая может развертываться и запускаться самостоятельно. Возможности системы (функции, площадки) реализуются как отдельные подсистемы. Полная функциональность системы появляется после запуска всех очередей.

Применяется при внедрении приложений класса ERP, CRM, CPM, любых комплексных многофункциональных бизнес-приложений.

Отличие от каскадной модели в том, что мы заранее не знаем один из двух параметров проекта – время или «географию». Кроме того, инкрементная модель ЖЦ применяется к серии проектов (часто называется программой). Каждый проект в отдельности выполняется согласно каскадной модели, а программа в целом – по инкрементной. То есть мы имеем дело с гибридной моделью ЖЦ проектирования АСУП.

Эволюционная (рис. 5.3)

В эволюционной модели система эволюционирует – целиком проходит весь ЖЦ, но отдельными очередями, то есть пока запущен первый релиз, готовится второй (всей системы), за ним следующий и т. д. Требования к системе в целом постоянно меняются (нет возможности установить все сразу). Всякий раз она запускается целиком. Подсистем быть не может.

Рис. 5.2. Схема инкрементной концепции ЖЦ

Рис. 5.3. Схема эволюционной модели ЖЦ

Применяется при:

эксплуатации и развитии ERP-приложения или любого другого комплексного приложения;

• разработке дополнительных функций эксплуатируемой АСУП;

• разработке самостоятельных комплексных приложений.

Знание теории ЖЦ поможет вам:

1) самостоятельно строить планы реализации вашей АСУП;

2) оценивать правильность методологических подходов, предлагаемых консультантами по внедрению той или иной бизнес-платформы;

3) подбирать для себя ту или иную модель ЖЦ системы в зависимости от того, какое приложение вы внедряете и каковы исходные условия проекта (программы).

Важно: При составлении договора на внедрение бизнес-приложения(ний) прописать тип используемой модели ЖЦ, потому что модель – это отправная точка для оценки качества проекта.

Приложения (см. методическое руководство «Теория жизненного цикла систем» на CD).

5.3. МСФО и управленческий учет

Международные стандарты финансовой отчетности (МСФО; англ. International Financial Reporting Standards) – набор документов (стандартов и интерпретаций), регламентирующих правила составления финансовой отчетности, необходимой внешним пользователям для принятия ими экономических решений в отношении предприятия. Данные стандарты приняты как обязательные в нескольких странах Европы. В большинстве стран Европы отчетность в соответствии с МСФО обязаны подготавливать компании, чьи ценные бумаги обращаются на бирже.

С 1973 по 2001 год стандарты разрабатывал Комитет по международным стандартам финансовой отчетности (Board of the International Accounting Standards Committee; IASC) и выпускал их под названием International Accounting Standards (IAS). В 2001 году IASC был реорганизован в Совет по Международным стандартам финансовой отчетности (IASB). В апреле 2001 года IASB принял (adopted) существовавшие IAS и продолжил работу, выпуская новые стандарты под названием IFRS.

В отличие от некоторых национальных правил составления отчетности, МСФО представляют собой стандарты, основанные на принципах, а не на жестко регламентированных правилах. Чтобы в любой практической ситуации составители могли следовать духу принципов, а не пытаться найти лазейки, которые позволили бы обойти какие-либо базовые положения. Среди принципов: принцип начисления (accrual basis), принцип непрерывности деятельности (going concern), осторожности (prudence), уместности (relevance) и ряд других.

В 1998 году в России принята и исполняется программа реформирования бухгалтерского учета в соответствии с МСФО. В частности, с 2005 года все кредитные организации обязаны подготавливать отчетность в соответствии с нормами МСФО.

Национальный совет по стандартам финансовой отчетности (Фонд НСФО) ведет работу по созданию комплекта национальных стандартов финансовой отчетности (СФО) с июня 2006 года.

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

Связь управленческого учета и МСФО

В главе «Политика управленческого учета» мы уже рассказывали о том, что многие (большинство!) предприятий в качестве стандарта УУ руководствуются принципами МСФО. Это разумно вдвойне: во-первых, не нужно ничего выдумывать – стандарты уже есть и хорошо описаны. Во-вторых, внедрив у себя УУ в формате международных стандартов, вы впоследствии сможете легко использовать накопленный опыт, чтобы регулярно составлять отчетность в соответствии с МСФО.

Некоторые компании подходят к формированию международной отчетности, как к ведению бухгалтерской. Выделяется отдельное подразделение – один-два или более человек, которые занимаются перекладкой уже сформированной РСБУ-отчетности. Если фирма не собирается использовать МСФО как инструмент управления, этого недостаточно.

В идеале принципы ведения УУ должны быть выстроены по МСФО. Это позволяет устранять разногласия и избегать ошибок, вызванных некомпетентностью вашего внутреннего персонала.

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

Для начала вы должны определить место МСФО в бизнесе своей организации. Минимальный перечень вопросов, которыми необходимо задаться при организации у себя МСФО:

• Кто будет готовить (не аудировать) МО? Вы сами или внешние консультанты? Насколько большие вы готовы произвести изменения в текущем учете?

• Вы предпочтете параллельный учет или трансформацию?

• Нужна индивидуальная отчетность по МСФО либо отчетность необходимо передавать в вышестоящую организацию для консолидации?

Ответить на эти вопросы мы постараемся в следующей разделе. Всем ли организациям необходимы МСФО

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

Рис. 5.4. Результаты опроса сайта E-xecutive.ru и Международного центра конференций OnConference, 2004 год

Западные или российские инвестиционные фонды рассматривают в качестве таковых МСФО. Так же поступают инвестиционные аналитики, сравнивая компании друг с другом. Не стоит забывать и о принципе сопоставимости показателей за разные периоды времени[28].

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

Практические пути получения международной отчетности

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

С точки зрения структурного описания международную отчетность (МО) делят на индивидуальную и консолидированную. Консолидированная всегда представляет собой агрегированные данные индивидуальных отчетов дочерних компаний.

В случае с консолидированной отчетностью часто возникают сложные моменты, например необходимость консолидации данных одной и той же дочерней или контролируемой компании в нескольких разрезах. Такие процессы консолидации возможны только с применением систем класса ERP или CPM.

Рис. 5.5. Пример сложности построения консолидированной отчетности

Есть два варианта перекладки индивидуальной отчетности, которые отличаются степенью необходимой точности (рис. 5.6):

1) перекладка суммарных данных за период – трансформация;

2) перекладка каждой транзакции – конверсия.

Рис. 5.6. Консолидация в холдинговых структурах

Последний вариант может осуществляться в режиме параллельного ведения двух учетов (параллельный учет) либо путем интерпретации каждого учетного события в двух стандартах сразу (потранзакционно). Параллельный учет – самый неэффективный. Поэтому, говоря о конверсии, мы будем подразумевать автоматическое отражение каждого учетного события в двух стандартах – РСБУ и МСФО.

Плюсы и минусы каждого варианта перекладки представлены в табл. 5.2.

Таблица 5.2. Конверсия и трансформация

Общие для обоих способов требования к системе:

• возможность настройки так называемого мэпинга – соответствия счетов РСБУ счетам МСФО (отображения) и алгоритмов перекладки;

• возможность «сверления» данных.

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

Альтернативные мнения

Тем не менее, многие компании, даже организовав у себя управленческий учет, для генерации международной отчетности используют данные российского бухгалтерского учета. Д. Новоселов: «Отчетность по МСФО мы составляем методом трансформации данных российского бухгалтерского учета в МСФО. Хотя, возможно, когда-нибудь перейдем к параллельному учету. Мы постепенно двигаемся в этом направлении – пока привели российский учет в соответствие и с отечественными стандартам бухгалтерского учета, и со стандартами МСФО. Там, где это возможно. В России создано неплохое законодательство, оно позволяет в широком спектре делать подобные изменения».

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

Б. Рябов: «Есть мнение, что МСФО можно брать за основу УУ. Так сразу убиваешь двух зайцев. Было время, когда русский бухгалтерский учет значительно отличался от МСФО. Но сейчас он дрейфует в сторону международных требований. Такова политика «партии», и она разумна.

Конечно, есть принципы по гармонизации стандартов финансового учета и МСФО. МСФО – более универсальный учет, и практического смысла в нем больше. Другое дело, что и там нет всех ответов. МСФО – принцип, детали компания изобретает сама. Мне кажется, проблема даже не в том, какие принципы будут заложены в процесс построения финансовой отчетности. Важнее разобраться со сбором первичной информации, особенно в отраслях, где информационный поток массивен. Нужно понимать, что пользователи финансовой отчетности – не единственные пользователи экономической информации, которые есть в компании. Еще имеются тактические решения. А их принимают исходя из данных о компании, но не элементов сбора финансового учета. Надо видеть всю картину. Информацию не спрятать; есть правила и есть пользователи; каждому необходимо что-то свое. Если управление информацией компании поставлено правильно, ответственность возникает не только за результат отчета некоего типа, как часто бывает (например, финансисты готовят учетную информацию). Ответственность должна быть за источники и за качество сведений. Это более жизнеспособно. Опять же, касается отраслей, где плотность информационного потока очень высокая.

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

Надо понимать, что МСФО, УУ – верхушка айсберга по сбору и обработке управленческой информации. Все начинается с первички. И деньги идут от этого, потому что в итоге затраты на деятельность по сравнению с ценностью экономических решений, в которых невозможно подменить основной сбор информации, незначительны. Потому что если нет стандартного процесса, нет вообще никакого».

Примеры перекладки отчетности

Кейс № 1

Тип предприятия: производственное. Структура МСФО отчетности: индивидуальная. Вариант перекладки: конверсия (потранзакционно) Инструмент перекладки: Oracle EBS.

Путь перекладки: РСБУ – МСФО. Данные РСБУ достаточно детальные, чтобы на их основе получать управленческую отчетность.

Параметры проекта:

Срок реализации – три месяца.

Значений счетов МСФО в главной учетной книге (ГК) – 4000. Значений счетов РСБУ в ГК – 400.

Штат специалистов МСФО: один методолог + один контролер. Частота конверсии – ежемесячно.

Кейс № 2

Тип предприятия: розничная сеть. Структура МСФО отчетности: консолидированная. Вариант перекладки: конверсия (потранзакционно). Инструмент перекладки: Oracle EBS.

Путь перекладки: Технический учет (регистрация всех учетных событий в EPR-прило-жении) – Одновременно: РСБУ, УУ и МСФО. Данные технического учета достаточно детальные, чтобы на их основе получать все три вида отчетности.

Цифры проекта

Срок реализации – три месяца.

800 000 операций и 1200 автоматических корректировок в месяц.

Более 250 выделенных бизнес-подразделений. Более 20 юридических лиц.

Около 200 финансовых контролеров.

Значений счетов МСФО в главной учетной книге (ГК) – 1000. Значений счетов УУ в ГК – 2000.

Штат специалистов МСФО: три методолога (не полная занятость).

Кейс № 3

Наименование предприятия: ОАО «Связьинвест».

Тип предприятия: телекоммуникационный холдинг, контролирующий семь межрегиональных компаний, каждая из которых представляет собой отдельный холдинг, являющийся ОАО. В целом организационная структура «Связьинвеста» содержит более 80 региональных предприятий и более 1000 структурных подразделений. Структура МСФО отчетности: консолидированная. Вариант перекладки: трансформация в реальном режиме времени. Инструмент перекладки: Infor MPC.

Путь перекладки: РСБУ МРК– МСФО МРК (консолидированные по каждой МРК в отдельности) – МСФО всего холдинга.

Параметры проекта

Первый релиз системы – четыре месяца.

Значений счетов МСФО в главной учетной книге (ГК) – 1000. Значений счетов РСБУ в ГК – 2000.

Пользователей: около 900 (находятся во всех часовых поясах и регионах РФ). Штат специалистов МСФО: около 20. Частота трансформации – два раза в год.

Выводы

Построение УУ по принципам МСФО выглядит логичным по той причине, что последние стандарты:

1) уже описаны;

2) понятны профессионалам в области финансов;

3) могут «подготовить» вас к генерации полноценной МСФО-отчетности.

Конверсия – самый эффективный способ отображения учетных событий в нескольких стандартах: РСБУ + УУ + МСФО. Однако этот способ очень требователен к методологическому описанию учетных процессов и наличию полнофункционального бизнес-приложения.

5.4. Роль финансового директора во внедрении и развитии УУ, или «Последние дни» CFO

Управленческий учет – это финансовое описание бизнес-процессов.

Е. Плаксенков

В данном разделе мы решили заострить внимание на ключевой фигуре вашей организации – финансовом директоре. Последние годы все говорят о том, что в процессе развития компаний и рынков происходит переосмысление роли финансового директора – Chief Financial Officer (CFO). Но в чем конкретно заключаются изменения? Ведь 80 % из 300 опрошенных KPMG CFO[29] «средних» компаний по-прежнему лишь контролируют затраты.

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

Но есть и хорошая новость: финансовые директора преуспевающих компаний (международных и российских) все яснее понимают, куда двигаться, как меняться, какую роль играть, а главное – какие на этом пути есть проблемы. Многие финансовые директора становятся публичными персонами, объясняющими с финансовой точки зрения стратегию компании вне зависимости от того, частная она или публичная. CFO все активнее участвуют в формировании IT-пространства своей организации.

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

Интерактивный on-line-обзор CFO Research Services необычайно интересен. В нем приняло участие более 1600 специалистов финансового сектора, причем более половины – сотрудники компаний с оборотом от полумиллиарда долларов. Главный вопрос – личный: «Считаете ли вы себя активистом?» Сам факт того, что этот вопрос задается, показывает, как изменилось отношение к финансистам. От них ждут уже не просто правильных цифр в нужное время, но активной позиции. Финансисты, читающие эти строки: считаете ли вы себя не просто «оптимистами», а «активистами»? 40 % участников опроса ответили, что они – активисты. Остальные, видимо, вырвались из рутины только для того, чтобы поучаствовать в опросе. Большинство активистов сотрудничают с советом директоров и учредителями своей компании более двух лет. То есть основной критерий активности финансового директора – взаимодействие; постоянное и «проактивное» взаимодействие с акционерами.

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

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

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

– Навигаторы роста (52 %)

банки, фармацевтика, high-tech, профессиональные сервисы

– Маэстро исполнительности (28 %)

энергетика, страхование, транспорт, retail, отели/рестораны

– Офицер реформ (12 %)

автопром, средства производства, электроника, пищепром, телеком

– Инноватор бизнес-модели (8 %)

здравоохранение, потребительские товары, риэлторы, финансы

CFO жалуются: взаимодействие с советом директоров – сплошной стресс. Но та же статистика из того же опроса говорит о том, что, если вы все-таки выдержали натиск и общаетесь с советом директоров около двух лет, психологический дискомфорт сходит на нет, общение переходит в русло нормальной работы. И финансовые директора становятся генеральными…

Так, кстати, произошло с нашим экспертом – Евгением Плаксенковым. УУ в своей компании он внедрял в качестве CFO. «В процессе организационной настройки управления финансами я немного стандартизировал структуру. Финансы – область, которая делится на пять основных частей: финансовый учет, управленческий учет, бюджетное управление, планирование инвестиций и управление стоимостью (стратегическое управление финансами). Под них мы сформировали специализированные подразделения, пять структурных единиц, пять лидеров, и у каждого свое бизнес-приложение».

Затем «высшим» пользователем формируемой в результате внедрения УУ информации Евгений стал уже в качестве CEO.

Другим ярким примером изменений роли CFO в организации стала история, случившаяся в 2006 году с финансовым директором компании Lego Сереном Линдгаардом[30].

Если мы сегодня посмотрим на результаты частной (оборот чуть больше 1 млрд долларов) Lego за 2006 год – все превосходно. Это был первый год, когда после долгого перерыва компания получила прибыль, причем большую. А что этому предшествовало?

Таблица 5.3. Прибыль компании Lego в 2005–2006 гг.

Компания Lego – создатель красивых и популярных развивающих игрушек – в 20032004 годах несла жуткие убытки (табл. 5.3). Многие топ-менеджеры Lego списывали их на то, что в мире падает рождаемость и на первый план выходят электронные игрушки. В общем, виноваты все, кроме них самих. В конце 2004 года Lego встала на путь серьезных реформ.

Для этого они пригласили нового финансового директора. Он начал с очевидных шагов: продажа непрофильного бизнеса, реструктуризация активов, освоение аут-сорсинговых моделей. Его дальнейшие действия оказались более сложными – речь шла о внутренних преобразованиях. Линдгаард придумал новый критерий оценки эффективности деятельности: КПП – прибыльность продукта и клиента. Это система показателей и отчетности, которая пронизывает организацию в целом. Она немедленно «открывает глаза» всем сотрудникам на то, чем они занимаются, сколько реально прибыли им приносит каждый клиент и каждый продукт. Основными целями КПП были упрощение планирования отчетности, эффективность операций и собственно обучение – постоянное обучение сотрудников. Второе, что сделал CFO – решил обучать основам финансов всех сотрудников организации, потому что каждый должен понимать экономику и разбираться в таких вещах, как эффективность бизнеса. Линдгаард внедрил единую ERP-систему по всем подразделениям и компании в целом, создал единый центр финансовых услуг – сервис, который позволяет централизованно обрабатывать все финансовые операции. С его помощью услуг компания Lego смогла оценить, какие операции делаются эффективно, а какие нет. Результаты сравнения ошеломили: 60 % времени всех сотрудников тратится на низкоуровневые операции (например, на оформление счета) и 10 % – на принятие решений. Понятно, что такая ситуация не может вывести компанию на прибыльность.

Таблица 5.4. Результаты фазы выживания

Перечисленные меры позволили новому финансовому директору за считанные месяцы сделать так, чтобы клиенты компании (тот же Wall-Mart) стали отзываться о Lego восторженно – совсем не так, как раньше.

Результат фазы выживания (табл. 5.4): от маржи 6,6 за 2005 год (почти в два раза меньше, чем у любого из конкурентов) к 19,5 в 2006 году (№ 1).

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

Все это необходимо, чтобы перейти к третьей фазе, называющейся просто «Рост, рост!»

«Я считаю, что на нашем быстроменяющемся рынке главным качеством финансового директора или другого топ-менеджера является непрерывное саморазвитие и готовность к переменам, ориентация на западный опыт и осознание того, что их достижения будут забыты завтра же, а серьезные ошибки – никогда», – сказал в одном из интервью Виталий Подольский, финансовый директор ТД «Перекресток». – Линдгаард – молодец. Однозначный профессионал в своей области. И, конечно же, не «кассир». Он – «спасатель широкого профиля»».

В статье, озаглавленной «Организоваться, чтобы создавать ценность», Дэвид Нортон утверждает: «Слово «ценность» стало синонимом выражения «нематериальные активы», что заключает в себе намного больше, чем просто финансовый менеджмент». Далее он задает вопрос: кто должен осуществлять процесс создания ценности внутри организации? И предполагает, что хотя финансовые директора обладают умением осуществлять эту функцию, только немногие занимаются этим на самом деле. Нортон говорит, что на исполнительном уровне может появиться новая должность для решения данной проблемы – директор по ценности (Chief Value Officer, CVO).

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

Д. Новоселов: «Последние четыре года я ощутил смену собственных приоритетов. От решения задач бюджетирования я пришел к тому, что компании больше необходимо управление стратегическими задачами. Управление ее стоимостью, конечно, да, но финансовый директор не один отвечает за стоимость; не один делает бюджет и не один его исполняет».

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

На примере растущей компании попробую нарисовать общую картину. Фирма начинает агрессивно расти. Что это значит? Сначала возникает огромная потребность в рабочей силе, затем – в инвестициях. У компании – плохой денежный поток. Растущая организация должна вкладываться в дебиторку – это потребность в рабочем капитале, инвестициях и новых объектах, генерирующих новые денежные потоки. А если финансовый директор заранее не решит, как будут амортизироваться активы? Ведь чтобы платить меньше налогов, надо сделать большую амортизацию. При этом инвесторы смотрят на один показатель – отношение долга к EBITDA. EBITDA будет максимальная, прибыль – достаточно маленькой (мы платим проценты за кредиты и амортизируем), налоги тоже. Денежный поток улучшается, а EBITDA растет, и мы можем привлечь много денег. Такое простое решение позволит компании развиваться, больше инвестировать И это все на фоне увеличивающейся конкуренции между финансовыми директорами. Есть две компании: одна – владелец актива, вторая пытается к ней присоединиться. Обе будут стремиться создать совместный инвестиционный проект. В то же время происходит битва умов на финансовом уровне. Потому что каждая компания хочет получить лучшие условия и самую выгодную часть проекта, максимальный денежный поток и окупаемость. Если актив – прибыльный и его хватит на всех – одно дело, а если куш невелик, участники вступят в жесткое противоборство. Могут и не договориться. Но не факт, что это будет плохо. Кроме переговоров бизнес-менеджеров, здесь еще важно и качество работы финансового менеджера. Как он просчитал инвестиционную политику и как повлияет вхождение в инвестиционный проект на состояние организации. Впишется ли проект в ту систему, о которой я говорил раньше, – по максимизации EBITDA при одновременном снижении налогового бремени. Нюансов – масса.

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

Это я все к тому, что финансовый директор становится стратегом, частью бизнеса; пусть даже не той, которая формирует стоимость компании. Как я уже сказал, бухгалтер формирует реальность. Значит, финансовый директор, который нанял этого бухгалтера, влияет на формирование реальности: взял на работу хороших людей – получилась хорошая реальность, если спецы так себе – реальность соответствующая. Опять же про игры разума – любая финансовая отчетность тоже превращается в игру. Все зависит от того, как мы это проведем. Один и тот же актив можно оформить по-разному: часть отнести на текущие расходы, половину – на капитализацию. Финансовые результаты будут разные, и результат у компании – тоже. И все виды отчетности, включая МСФО, направлены лишь на то, чтобы как можно прозрачнее представить замысел бухгалтера. Убедить всех внутренних пользователей – тоже проблема. С моей точки зрения, основная проблема финансов – общечеловеческая. У каждого есть кошелек с деньгами. Если я умею их тратить, наверное, я что-то смыслю в финансах. Это общечеловеческий подход. И если о маркетинговых решениях никто не спорит, то о финансовых решениях может спорить каждый, до бесконечности. Закон Паркинсона есть, когда он рассказывает о проведении бюджетного комитета, где каждый знает, сколько стоит чашка кофе, и никто – цену ядерного реактора. Про реактор никто не спорит, а про то, что кофе сотрудникам в офис за 20 – дорого, все кому не лень.

5.5. Что бы мы сделали по-другому

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

Мы также ошиблись в формировании требований по организации интерфейса между внедряемыми системами, так как заранее не спрогнозировали, сколько времени займет сведение воедино всех систем. Из-за этого даже пришлось перезапускать проект (стоило денег и времени). Еще один урок!

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

Касательно выбора бизнес-приложений не могу сказать, что мы ошиблись. Каждый раз предпочтение отдавалось в пользу лучшего решения».

Е. Плаксенков: «Любая постановка управленческого регулирования в процессе реализации приводит к новому пожеланию. Рождаются вариации: «можно так, а можно по-другому», «а правильно ли мы идем?», «а давайте сделаем не так». И в этот момент всегда есть вероятность поддаться соблазну «доделок». Например, вы создаете самолет, и в какой-то момент, когда он уже почти готов, вам говорят: «Давайте сделаем так, чтобы в самолете можно было не только летать, но и плавать». Вы отвечаете: «Точно, давайте приделаем к самолету парус…» И добавляют: «А еще, чтобы самолет мог копать, давайте лопату приделаем». Эти желания и «давайте еще» – самые опасные, потому что у человека, по-настоящему включившегося в процесс и увлеченно над чем-то работающего, автоматически рождаются новые идеи. Надо уметь реализовать задуманное ранее, при этом не забыть идеи и не нарушать идеями стройную картину, которую решили воплотить в жизнь. Наметил проект – реализуй. А сгенерированные по ходу новые идеи необходимо сохранить, чтобы с их помощью обогатить полученный результат. Я твердо уверен: любой проект, особенно финансовая постановка управленческого учета, должен стремиться к максимальному сокращению сроков реализации. Чем он длиннее, тем больше изменений возникнет. А они, в свою очередь, могут привести к корректировке проекта и срыву сроков.

Тем компаниям, которые лишь приступают к постановке управленческого учета, я бы порекомендовал следующее. Руководителю нужны три вещи:

1. Понимание бизнеса как системы.

2. Понимание его роли в отрасли, экономике и на рынке. Если ты понимаешь свой бизнес как систему, ты осознаешь его роль, понимаешь структуру, цели и т. д.

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

Д. Новоселов: «Что бы мы сделали сейчас по-другому? Четыре года назад внедрили бы SAP или аналогичную ERP с помощью консультантов. Существует мнение, будто от системы мало что зависит и если все нормализовать, можно обойтись и без нее. Но это не так. У нас проблема не с самой «Галактикой», а с тем, как мы ее внедрили и настроили. Было допущено много ошибок – в бизнес-процессах и их описании, во время внедрения и настройки. А когда в системе уже ведется учет, исправить сложно. Некоторые проблемы, чтобы исправить, еще надо найти. Программисты, с которыми мы работали, зачастую не понимали, зачем они все это делают, а экономисты не понимали, как оно работает и что внутри. Консультанты необходимы для связки – они должны понимать, какие конечные требования по бизнес-процессам существуют у пользователя и как настроить систему, чтобы одно требование не противоречило другому. При качественном внедрении системы с их участием данное правило обычно выполняется.

В качестве дополнительных преимуществ внедрения полноценной ERP-системы я вижу реализацию целого ряда механизмов внутреннего контроля. Простой пример, реализуемый даже в «1С»: существует контрагент, цена единицы товара указана в накладной. Маленькая проверка, которая под силу учетной системе, – сравнить текущую цену накладной с ценой, которая занесена или статистически сложилась в справочнике цен. В чем заключается проблема введения накладных? Оператор может вместо рублей ввести доллары либо евро, напутать с единицами измерений. При этом он может полениться все еще раз проверить или просто не заметить – цифры правильные, а в систему ушла накладная с ошибкой. Эти ошибки рано или поздно будут обнаружены, но придется потратить дополнительные ресурсы на проверку, что снижает доверие к системе и скорость работы в целом. Правильнее и в конечном итоге эффективнее организовать простые проверки на входе в систему и элементарно отслеживать такие огрехи.

Вот несколько алгоритмов, которые позволяют не совершить подобных ошибок: при вводе валюты и при проведении платежа в учетной системе сверяться со справочником цен. Если цена отличается больше, чем на 20 % (10 %), выскакивает предупреждение: «Цена отличается на столько-то. Вы уверены?». Если пользователь выбирает: «Да, уверен», все хорошо. Если нет, он начинает проверять и обнаруживает, что ввел не ту валюту либо не ту ставку НДС, еще что-то упустил. Такие инструменты можно придумать на любом участке учета и быть уверенным – все первичные документы введены правильно. Подобные элементы контроля стоит предусмотреть в момент внедрения системы. Уже имеющуюся ситуацию можно изменить коренным образом, только внедрив новую ERP-систему или перевнедрив существующую (сопоставимо по ценам). К сожалению, внедрение полноценной ERP, например SAP, для нас сегодня дорого и, наверное, на данном этапе жизни компании не оправданно».

Всегда очень важно не слишком поздно и не слишком рано что-либо внедрять.

Приложения

1. Руководство по целеполаганию

Область применения

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

Определения

1. Автоматизированная система управления предприятием (АСУП) – автоматизированная система управления, объектом управления которой являются бизнес-процессы предприятия. АСУП является частью системы управления предприятия. Политика и цели в области автоматизации управления являются частью политики и целей компании.

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

3. Целеполагание – вид работ, результатом которых является согласованный комплекс (иерархия) целей. Целеполагание выполняется по определенным правилам и в соответствии с общими методическими требованиями.

4. Цели компании – цели, характеризующие состояние и процессы компании, которые планирует достичь руководство, акционеры компании в плановом периоде.

5. Цели проекта – цели, характеризующие состояния и процессы объектов проектирования (не предмета), которые планируется достичь путем успешного осуществления проекта в заданных условиях (рамках) его реализации.

6. Цели процесса – цели, достижение которых характеризуется значением параметров процесса по основным критериям результативности, установленным при планировании результатов деятельности на период.

Назначение целеполагания

В соответствии с определением [3] целеполагание предназначено для формирования иерархии (дерева) целей. Это может происходить в следующих случаях:

• при стратегическом планировании развития компании;

• при планировании бизнес-процессов (деятельностей компании);

• при создании или развитии системы управления;

• при планировании проекта (очереди) или стадии работ.

Целеполагание позволяет решать следующие задачи:

• обеспечивать превентивность управления;

• уменьшать риски проекта;

• концентрировать усилия и ресурсы на главных направлениях;

• повышать предметность и осмысленность планов;

• повышать эффективность деятельности;

• реализовывать целевой процесс управления деятельностью;

• обосновывать выбор возможных вариантов проектных решений;

• обоснованно использовать ресурсы;

• вовлекать персонал в процесс управления деятельностью;

• повышать «командный дух», активность и мотивацию персонала;

• проводить обоснованный анализ результатов деятельности.

Принципы целеполагания

Целеполагание – задача неформализованная. Однако можно указать десять общих принципов, помогающих ее логично и эффективно решать:

• идейность;

• полезность;

• достижимость;

• направленность;

• понятность;

• предметность;

• измеримость;

• независимость;

• подчиненность;

• актуальность.

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

Идейность

Цель должна соответствовать политике. Политика определяет и реализуется через цели. Политика содержит описание ключевых ценностей организации. Политика включает миссию и видение. Цели являются связующим звеном между политикой (идеями) и мероприятиями (деятельностью) по ее воплощению.

Полезность

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

Достижимость

Цель должна быть достижима в рамках границ деятельности, сроков и ресурсов. Если цель недостижима в рамках деятельности (процесса, проекта, стадии, очереди), значит – это цель деятельности более высокого порядка и ее необходимо детализировать до уровня, когда можно оценить достижимость.

Направленность

Цель должна быть внешней по отношению к предмету определения (системе). Цель должна быть вне создаваемой системы или улучшаемого процесса. Если цель оказалась сформулирована в виде одной из внутренних характеристик самой системы, то улучшения не будут отражаться на ее взаимодействии с окружающей средой, и деятельность окажется бесцельной. Таким образом, цель должна быть направлена на преобразование во времени целевых характеристик внешней среды предмета целеполагания[31].

Понятность

Цель должна быть сформулирована просто и ясно. Только в этом случае цель будет одинаково адекватно восприниматься всеми участниками деятельности, а оценки критериев цели – однозначно истолковываться.

Предметность

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

Формулировка цели должна включать контекст предметной области.

Измеримость

Цель должна быть измеримой. Только измеримые цели позволяют сравнивать системы или варианты их реализации между собой по степени предпочтительности относительно данной цели. Цели измеряются с помощью критериев. Измерение, контроль и анализ обеспечивают обратную связь процесса управления.

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

Независимость

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

Подчиненность

Цели деятельности нижнего уровня должны быть подчинены целям деятельности более высокого уровня. Так, цели проекта должны подчиняться целям вида деятельности, к которой относится проект, а цели деятельности – целям компании.

Актуальность

Определение целей имеет смысл только при указании контрольного срока их достижения. Иначе достижение цели становится неуправляемым во времени. Могут существовать промежуточные цели и сроки переопределения целей.

Общие рекомендации по целеполаганию

Квантификация целей

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

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

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

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

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

Выбор критериев

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

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

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

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

• какую характеристику можно, а какую нельзя использовать в качестве критерия для данной схемы;

• какова степень адекватности критерия для данной системы;

• какова степень адекватности критерия и сформулированной ранее цели;

• насколько максимум (минимум) критерия соответствует выбору оптимальной системы.

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

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

Шкалы измерения критериев

После назначения критерия и установления возможности его практического использования необходимо определить его значения для всех рассматриваемых систем. Измерение или расчет значений критерия может производиться только по какой-либо заранее определенной шкале. Каждая шкала имеет свою информативность и свой класс допустимых преобразований, за пределы которого нельзя выходить без риска получить бессмысленные или ошибочные результаты.

Шкала наименований (категорий)

Критерии представляют однозначную числовую оценку системы безотносительно ее свойств.

В этой шкале число используется лишь для обозначения и выделения системы или другого объекта (страницы книги, инвентарные номера и т. п.).

Сравнение систем в этой шкале может принимать только значения в бинарном коде «да-нет» или «равно-не равно».

Ранговая (порядковая) шкала

В отличие от предыдущей шкалы, значения критериев ранжированы в соответствии с отношениями предпочтительности систем.

Критерии в этой шкале позволяют сравнивать две системы по принципу «лучше-хуже».

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

Шкала интервалов

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

Интегральные критерии

Наличие интегрального критерия решает проблемы многокритериальности наиболее радикальным способом – за счет «свертки» набора критериев в один критерий, эквивалентный с точки зрения системы предпочтений заказчика этому набору.

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

Формат определения целей

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

Общие требования к формату цели

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

Таблица 1. Формат определения целей

Возможные отклонения от общих требований

В случае, когда проект имеет несколько последовательных очередей, следует определить общие цели проекта концептуально (без целевых значений), а для каждой очереди определить конкретные целевые значения по критериям.

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

В случае, когда предполагается по умолчанию, что цели проекта по созданию АС должны быть достигнуты сразу после приемки АС в промышленную эксплуатацию (совершенно не очевидно), можно не указывать срок достижения цели.

Связь целей компании, процессов и проектов

Значительная доля проблем, связанных с неудовлетворительным ходом реализации АСУП на предприятиях заказчиков и неуспехом реализуемых проектов, связана с недостаточным вниманием к формированию и отслеживанию достижения целей проекта (создаваемой системы).

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

Правильное определение целей проекта – ключевой момент, который в целом определяет успех или провал работы по созданию АСУП и ее подсистем.

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

Цели компании

Руководство компании устанавливает стратегические, тактические и оперативные цели деятельности компании, отвечающие интересам владельцев и декларируемой политике.

Планирование деятельности компании на всех уровнях должно руководствоваться достижением целей соответствующего уровня. Любая деятельность, процесс компании должна осуществляться и совершенствоваться в направлении достижения целей деятельности.

Цели бизнес-процессов

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

Важно не переусердствовать и не увлечься количеством целей. Их должно быть немного: от одной до трех целей верхнего уровня на процесс. Также нужно стремиться минимизировать количество уровней иерархии дерева целей. Желательно, чтобы их было не больше двух-трех, а количество детализирующих целей на каждом уровне – не больше трех. В любом случае, следует оценивать (измерять) и анализировать только цели нижнего уровня. Для квантификации целей могут использоваться различные виды классификаций: ССП, цикл Деминга, классификаторы бизнес-процессов (PCF, CALS, MRP II).

Цели создания АС

Прагматический аспект любого вопроса, проблемы или деятельности определяет их смысл или рациональность использования. Изначально искусственные системы[32] прагматических характеристик не имеют. Цели являются основными прагматическими характеристиками АС, так как позволяют определять целесообразность создания АС в оптимальном варианте. В общем случае смысл цели заключается в стремлении к более полному удовлетворению тех или иных потребностей общества, его отдельных групп, слоев или личностей. В данной интерпретации цели создания АС должны отражать потребности акционеров и высшего менеджмента заказчика.

Цель создания АСУ должна формулироваться в предметной области и определяется ее назначением. Если АСУ предназначена для управления, ее цели должны относиться к управлению конкретным объектом.

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

Цели создания АСУП формулируются в виде перечня наименований и требуемых значений показателей автоматизируемых бизнес-процессов объекта автоматизации, которые должны быть достигнуты в результате создания системы и критериев оценки их достижения. Цели создания АСУП при этом становятся частными критериями целей бизнес-процессов.

Ключевым содержанием цели создания АС является удовлетворение потребностей заказчика в совершенствовании управления бизнесом. При этом удовлетворяться могут потребности в ликвидации неудобств и проблем либо потребности в получении дополнительного положительного эффекта, не связанного с осознанными потребностями.

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

При автоматизации бизнес-процессов на предприятиях заказчика цели создания АС должны позволять проводить обоснованное сравнение вариантов автоматизируемых бизнес-процессов до и после реализации предлагаемого заказчику продукта или услуг.

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

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

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

Использование целей в проектах

Совместное целеполагание в проектах

Совместной называется такая деятельность в рамках проекта, в которой участвуют несколько заинтересованных сторон. Участие каждой определяется наличием необходимых ресурсов, ответственностью, компетенцией и полномочиями. В случае выполнения консалтинговой компанией проекта на объекте заказчика совместное целеполагание выполняется заказчиком (по его воле) при методическом участии специалистов (консультантов) исполнителя или исполнителем (непосредственно разработка целей) при обсуждении вариантов и согласовании целей заказчиком.

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

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

Разработка целей заказчиком

Целеполагание выполняется топ-менеджерами и владельцами процессов заказчика.

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

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

Разработка целей для заказчика

Целеполагание выполняется менеджером проекта и консультантами проектной группы при участии топ-менеджеров, функциональных менеджеров заказчика.

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

Разработка целей для заказчика не предполагает решения всего круга задач стратегического менеджмента. Рамки выполняемых работ должны ограничиваться разработкой целей деятельности в контексте предстоящего проекта автоматизации. Следовательно, если пользоваться классификацией ССП (системы стратегических показателей), достаточно ограничиться целями развития бизнес-процессов. Цели по остальным категориям следует разрабатывать, только если рамки проекта непосредственно затрагивают данные области (рынок, персонал, финансы). Кроме того, разрабатываемые цели должны быть, хотя бы частично, достижимы в рамках проекта.

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

Желательно до визита к первому лицу узнать о ключевых приоритетах руководства компании в основных областях деятельности (политику организации). Важной может оказаться информация о формальных и неформальных лидерах – акционерах и руководителях.

До визита к первому лицу нужно знать, кому он подчинен формально и де-факто.

При разработке и презентации целей следует пользоваться общими принципами, но адаптировать их к условиям проекта и объекта. Следует учитывать наработки, которые ранее велись в компании в области целеполагания; получить представление о ее видении и миссии; следовать, по возможности, используемым в компании методикам управления, терминологии и классификации, если они не противоречат стандартам, научным основам и собственной проектной методике.

Целесообразность и источники эффективности

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

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

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

Документирование целей в проектах

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

• минимизация количества целей;

• соблюдение общих принципов целеполагания, изложенных выше;

• согласованность и однозначность понимания целей всеми участниками проекта;

• максимальное покрытие целей бизнес-процессов соответствующими целями проекта;

• возможность покрытия поставленных целей проекта проектными решениями;

• реализуемость (техническая, финансовая, временная) в рамках проекта.

Обеспечение достижения целей проекта

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

Анализ успешности проекта

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

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

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

2. Положение о финансовой структуре

Общие положения

Цель документа

Положение о финансовой структуре составлено на основе принципов управления по центрам ответственности, определяющих построение и функционирование финансовой структуры как основного исполнительного механизма бюджетного управления Группы компаний (далее по тексту – ГК).

Целью создания данного документа является содержательное описание финансовой структуры ГК.

Данный документ описывает центры финансовой ответственности, выстраивает их иерархию, определяет степень финансовой ответственности структурных единиц за производимые действия.

Основные понятия

В данном разделе дается определение основным терминам и сокращениям, используемым при формировании финансовой структуры ГК.

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

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

Финансовая структура компании – иерархия центров финансовой ответственности, взаимодействующих между собой через бюджеты.

Центр финансовой ответственности (ЦФО) – структурное подразделение, осуществляющее определенный набор хозяйственных операций, способное  оказывать непосредственное воздействие на расходы и/или доходы от этих операций и отвечающее за величину данных расходов и/или доходов.

Центр финансового учета (ЦФУ) – структурное подразделение, которое ведет учет установленных для него показателей доходов и/или расходов, но не отвечает за их величину.

Область применения

Выполнение требований системы бюджетного управления, описанных в Положении о финансовой структуре и указанных в нем сопутствующих документах, обязательно для всех сотрудников ГК.

Положение применяется для:

• внутреннего использования при решении задач управления предприятием;

• обеспечения документированной базы системы бюджетного управления;

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

Принципы пересмотра и актуализации положения

Актуализацию настоящего положения, пересмотр и выпуск извещения об изменениях осуществляет финансовый директор ГК. Положение и изменения к нему утверждает бюджетный комитет (финансовые и генеральные директора группы, финансовый директор ГК).

Каждый сотрудник группы и Управляющей компании может представлять свои предложения по изменению или дополнению разделов настоящего положения бизнес-экспертам группы и Управляющей компании соответственно с обоснованием аргументов по предлагаемому вопросу. Вносимые изменения утверждает финансовый директор ГК.

Положение о финансовой структуре пересматривают в случае возникновения любых изменений, которые могут быть результатом корректировок в деятельности и/или стратегии ГК, предпринимаемых как для более полного и целенаправленного соответствия внутренним потребностям управления, так и требованиям внешней среды.

Корректировка настоящего положения может происходить как за счет замены одного из его разделов, так и за счет полной замены документа.

Каждому очередному варианту Положения присваивается порядковый номер с указанием даты разработки. Дата и номер варианта разработки являются его обязательными реквизитами и подлежат указанию при любом упоминании в документах.

Принципы формирования финансовой структуры

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

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

Финансовая структура определяет подчиненность, полномочия и ответственность ЦФО и формируется на базе организационной структуры.

ЦФО классифицируются по видам результатов своей хозяйственной деятельности. При этом основной задачей является выполнение своих заданий в рамках установленных бюджетом показателей.

Эффективность деятельности ЦФО определяется путем сравнения целевых (плановых) и фактических значений показателей. На основе анализа отклонений по показателям руководитель ЦФО оперативно принимает меры по достижению целевых (плановых) значений показателей, повышению эффективности деятельности центра финансовой ответственности. Руководители ЦФО несут ответственность за их деятельность и финансовые результаты.

В рамках управления по ЦФО выполняются следующие основные функции:

Планирование. Деятельность ГК планируется в формате бюджетов. Каждый ЦФО планирует свою деятельность в финансовом (и если необходимо, в количественном) выражении по статьям, консолидация которых позволяет сформировать соответствующие бюджеты для всей компании в целом. Согласованный и утвержденный руководством сводный бюджет компании является директивным планом на очередной период.

Контроль. Фактическое исполнение своего бюджета ЦФО сравнивают с планом в целях контроля над установленными показателями и предупреждения неблагоприятного развития ситуации как для руководства ЦФО, так и для вышестоящих структур ГК.

Отчетность. По окончании периода ЦФО готовят Отчеты о фактическом исполнении бюджета в формате, аналогичном бюджету с приведением данных анализа отклонений плановых значений от фактических. Все отклонения анализируются, выявляются причины их возникновения, готовятся мероприятия по устранению этих причин или предупреждению возникновения им подобных.

Мотивация. Выполнение бюджета отдельными ЦФО (и ГК в целом) рассчитано на достижение поставленных целей, для чего устанавливается зависимость материального вознаграждения от соблюдения/нарушения бюджета, которое должно мотивировать персонал и руководство ЦФО добиваться точного исполнения или улучшения бюджетных показателей.

В рамках финансовой структуры также выделяются центры финансового учета. Это подразделения, которые на момент утверждения данного документа напрямую не участвуют в процессе бюджетного управления, однако включены в финансовую структуру для отображения источника возникновения доходов и затрат. Ответственность за показатели, характеризующие деятельность этих ЦФУ, несут ЦФО верхнего уровня или подразделения-центры консолидации.

Виды ЦФО

В финансовой структуре выделяется шесть основных видов ЦФО:

• центр инвестиций;

• центр прибыли;

• центр дохода;

• центр маржинального дохода;

• центр затрат;

• центр дохода и затрат.

Данная классификация основана на разделении ЦФО по видам доходов/затрат, за которые они несут ответственность.

Центр инвестиций (ЦИ) – центр финансовой ответственности, руководитель которого имеет право управлять не только оборотным капиталом, но и внеоборотными активами организации (осуществлять инвестиции и их изъятие). Центр инвестиций контролирует окупаемость инвестиций, и таким образом отвечает за рентабельность всех подконтрольных активов, а также за объем прибыли, получение которой ожидается в будущем.

Центр прибыли (ЦП) – центр финансовой ответственности, руководитель которого отвечает за сумму полученной прибыли. Центрами прибыли выступают подразделения, способные оказывать воздействие на доходы и расходы в рамках своей деятельности; результат деятельности центра прибыли измеряется в виде разницы между получаемым им доходом и возникающими в нем затратами.

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

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

Центр затрат (ЦЗ) – центр финансовой ответственности, руководитель которого отвечает и контролирует только затраты. Центры затрат образуют подразделения, которые для выполнения своих функциональных обязанностей потребляют различные ресурсы и не приносят дохода непосредственно. Центры затрат определяют расходную часть бюджета организации.

Центр дохода и затрат (ЦДЗ) – центр финансовой ответственности, который представляет собой совокупность ЦД и ЦЗ одновременно, в то же время разницу доходов и затрат данного ЦФО нельзя определить как прибыль.

Структура центров финансовой ответственности

Структура центров финансовой ответственности предусматривает их разделение по уровням управления в зависимости от их подчиненности, целей и задач планирования и контроля.

Основные принципы децентрализации управления:

• формирование центров финансовой ответственности;

• распределение центров финансовой ответственности по уровням в зависимости от подчинения.

В настоящее время в ГК ЦФО распределяются по уровням ответственности следующим образом:

• ЦФО 1-го уровня – ГК;

• ЦФО 2-го уровня – Управляющая компания, компании;

• ЦФО 3-го уровня – центральные и региональные офисы, офис макрорегиона компаний, структурные подразделения Управляющей компании;

• ЦФО 4-го уровня – структурные подразделения (департаменты и отделы) центральных и региональных офисов;

• ЦФО 5-го уровня – строящиеся и действующие объекты торговой сети, а также региональные представительства.

Показатели деятельности, за которые отвечает ЦФО и по которым происходит его оценка, определяются независимо от уровня, к которому принадлежит ЦФО. В соответствии с этими показателями и функциональным назначением ЦФО, центры финансовой ответственности относятся к определенному типу.

Центры финансовой ответственности по уровням и типам

В табл. 1 приведен полный иерархический список всех ЦФО и ЦФУ, с указанием их уровней.

Таблица 1. Распределение центров финансовой ответственности по уровням

В табл. 2 приведен список ЦФО с указанием типа и уровня ЦФО и ЦФУ.

Таблица 2. ЦФО и ЦФУ и их типы

Полномочия и ответственность

Для каждого ЦФО определяется ответственный сотрудник, который несет персональную финансовую ответственность за своевременное составление планов по ЦФО и степень их исполнения. Эта информация представлена в табл. 3.

Таблица 3. Ответственные лица по ЦФО

Для повышения качества составления и исполнения планов для каждого сотрудника необходимо определить меру его ответственности за следующие события:

1. Значительные отклонения фактических показателей по бюджетам от запланированных.

2. Своевременное непредоставление плановой информации по ЦФО или предоставление некорректной информации.

3. Своевременное непредоставление фактической информации по ЦФО или предоставление некорректной информации.

Полномочия и ответственность в рамках процесса бюджетирования оформляются соответствующим документом («Регламент бюджетного процесса»).

Целевые показатели и показатели эффективности

Для центров финансовой ответственности Группы компаний разработан перечень показателей, характеризующих деятельность ЦФО.

Среди показателей выделены две группы:

1. Целевые показатели.

2. Показатели эффективности.

Целевые показатели представляют собой ряд показателей, используемых правлением ГК для установки направления и темпов развития бизнеса на следующий период.

Значения целевых показателей для групп компаний и УК ежегодно устанавливает Бюджетный комитет перед оформлением Генерального плана. После чего руководство групп компаний и УК трансформирует их в целевые показатели для отдельных ЦФО. При формировании бюджета на следующий год ЦФО обязаны придерживаться установленных целевых показателей (представлены в табл. 4).

Таблица 4. Целевые показатели

Показатели эффективности предназначены для оценки эффективности деятельности ЦФО и включают как финансовые, так и нефинансовые показатели. Они могут быть рассчитаны на основании данных систем учета, системы бюджетирования и иных источников. Перечень показателей эффективности приведен в табл. 5 данного документа.

Лицом, отвечающим за соблюдение показателей центром финансовой ответственности, является ответственный по ЦФО. Перечень ответственных лиц приведен в табл. 3 данного Положения.

Таблица 5. Показатели эффективности

Форматы бюджетных форм и отчетов, предназначенные для работы с показателями, приведены в приложении 2 к «Положению о бюджетном управлении».

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

3. Программа и методика испытаний

Общие сведения

Программа и методика испытаний – руководящий документ, регламентирующий проведение испытаний АС.

Цели документа:

• Повышение эффективности проведения испытаний.

• Упрощение организации испытаний.

• Снижение управленческих рисков.

• Получение нормативной базы для принятия решений по результатам испытаний.

Принятые в документе сокращения

РЦ – Распределительный центр. АС – Автоматизированная система.

Объект испытаний

Таблица 1. Общие сведения о системе

Общие положения

Перечень документов

В табл. 2 приведен перечень документов, на основании которых будут проводиться испытания АС.

Таблица 2. Перечень документов

Виды, место и продолжительность испытаний

Виды, место и продолжительность испытаний и ответственные определены в табл. 3.

Таблица 3. Этапы испытания АС

Перечень предъявляемых для испытаний документов

Проверке при проведении испытаний подлежат следующие документы:

1. Техническое задание на создание АС № 7.601.

2. Пояснительная записка к техническому проекту № 7.602.

Объем испытаний

Во время проведения первых двух этапов испытаний должны быть проверены все функции, описные в приложении № 1 к Техническому заданию на создание АС № 7.601, взаимосвязи между ними и работа всей системы в целом. Также необходимо проверить выполнение требований к функциям системы, приведенных в Техническом задании на создание АС № 7.601.

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

Перечень тестируемых функций определен специалистами Заказчика до проведения этапа испытаний «Тестовая эксплуатация» и представлен в приложении 1.

Условия и порядок проведения испытаний

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

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

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

При проведении приемочных испытаний производится проверка полноты исправления замечаний, зафиксированных в Журнале опытной эксплуатации. Приемочная комиссия осуществляет окончательную проверку проектных документов и АС в целом. По окончании приемочных испытаний комиссия делает вывод о готовности АС к приемке в Промышленную эксплуатацию.

Испытания завершаются оформлением Акта приемки АС в Промышленную эксплуатацию.

Методика испытаний

Тестовая эксплуатация

Тестовая эксплуатация проводится для проверки:

• механизма загрузки начальных данных в систему;

• функциональности АС;

• инструкций пользователей;

• механизма обмена информацией со смежными системами;

• готовности ключевых пользователей;

• корректности выходных данных АС.

Проверка механизма загрузки начальных данных в систему

Проверяется быстродействие, корректность, полнота механизма загрузки начальных данных в систему. Первоначальная загрузка данных не должна превышать 6 часов. Должны быть загружены все данные, определенные в Техническом задании на создание АС № 7.601. При выполнении набора тестов проверяется корректность загруженных данных.

Проверка функциональности АС

Проверяется соответствие функций системы требованиям, предъявленным к ним в Техническом задании на создание АС № 7.601.

Таблица 4. Критерии приемки функций АС

Инструкции пользователей

Проверяется их корректность и применимость при выполнении, удобство использования; если необходимо, производится коррекция документации.

Обмен информацией со смежными системами

С помощью специальных тестовых наборов проверяется корректность выгрузки и загрузки данных из смежных систем. Специально для этого будут развернуты тестовые системы: «1С: Торговля РЦ», «1С: Бухгалтерия», «Магазин Fox Pro».

Проверка готовности ключевых пользователей

Проверяются навыки выполнения функций ключевыми пользователями в соответствии с Техническим заданием на создание АС № 7.601.

Проверка корректности выходных данных

Проверяется корректность данных, получаемых из системы через отчеты и запросы.

Опытная эксплуатация

Опытная эксплуатация АС проводится для определения фактических значений количественных и качественных характеристик АС заказчика и готовности персонала к работе в условиях функционирования системы, определения фактической эффективности АС, корректировки (при необходимости) документации. Опытная эксплуатация проводится в режиме дублированного ввода данных в АС заказчика и ЦССК Fox Pro.

Проверка наличия и качества документации

Контролируется наличие документации, перечисленной в разделе 3.3 настоящего документа. Проверяется полнота содержащихся в эксплуатационной документации указаний персоналу по выполнению им функций во всех режимах функционирования АС заказчика, согласно Техническому заданию на создание АС № 7.601.

Проверка готовности персонала

Проверяется знание персоналом эксплуатационной документации и наличие у него навыков, необходимых для выполнения установленных функций во всех режимах функционирования АС заказчика, согласно Техническому заданию на создание АС № 7.601.

Контроль количественных и качественных характеристик функций АС

Контролируются количественные характеристики выполнения автоматических и автоматизированных функций АС в соответствии с Техническим заданием на создание АС № 7.601.

Проверка функциональности системы

Проверяется качество выполнения автоматизируемых функций во всех режимах функционирования АС. Проверка производится ключевыми и конечными пользователями в режиме реальной оперативной работы. Проверяемые функции могут быть отнесены к двум основным группам:

1. Функции и операции, проверка которых осуществляется в ходе оперативной работы в течение опытной эксплуатации системы.

2. Функции и операции в системе, которые не могут быть в полном объеме протестированы в ходе опытной эксплуатации и для подтверждения корректности выполнения которых требуется проведение дополнительного контрольного примера.

Для последних на этапе опытной эксплуатации разрабатывается, утверждается Приемочной комиссией и реализуется в системе набор тестов с документированием результатов в протоколе испытаний системы.

Проверка выходных данных системы

Проверяется корректность информации, получаемой из системы через отчеты и запросы. Документирование результатов

Ход испытаний фиксируется в Журнале опытной эксплуатации. На его основе определяются дальнейшие действия по доработке системы и/или готовность ее к приемочным испытаниям. При обнаружении неисправностей функционирования АС делается соответствующая запись в Журнале опытной эксплуатации, как это определено в п. 0.

Подписание протокола согласования

При возникновении новых требований для согласования дальнейшей разработки составляется протокол согласования, содержащий условия и сроки исполнения дополнительных требований.

Приемочные испытания

Приемочные испытания АС проводят для решения вопроса о возможности приемки системы в промышленную эксплуатацию.

Производится проверка соответствия системы требованиям, предъявленным в Техническом задании на создание АС № 7.601, а также качества реализации АС. Проверка осуществляется на основании Журнала опытной эксплуатации. Занесенные в него замечания должны быть исправлены или соответствующим образом отражены в протоколе согласования.

Программа тестовой эксплуатации

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

Таблица 5. Перечень задач стадии «Тестовая эксплуатация»

Программа опытной эксплуатации

Программа опытной эксплуатации (табл. 6) описывает последовательность задач по ее проведению. По каждой задаче есть ответственный исполнитель. Во время опытной эксплуатации в АС заказчика будут загружены реальные справочники и остатки. После этого в существующую АС и АС заказчика будут вводиться одинаковые данные и сравниваться результаты работы двух систем.

Таблица 6. Перечень задач стадии «Опытная эксплуатация»

Программа приемочных испытаний

В табл. 7 приведены задачи приемочных испытаний.

Таблица 7. Перечень задач стадии «Приемочные испытания»

Отчетность

В табл. 8 приведен перечень документов, разрабатываемых при проведении испытаний АС.

Таблица 8. Перечень документов

Состав приложений

Приложение 1. План тестирования АС

ЛИСТ СОГЛАСОВАНИЯ К ПРОГРАММЕ И МЕТОДИКЕ ИСПЫТАНИЙ № 03

4. Устав проекта

Общие сведения

Определение терминов и понятий

БИЗНЕС-ПРОЦЕСС – устойчивая, целенаправленная совокупность взаимосвязанных видов деятельности (операций), которая преобразует входы процесса в его выходы.

ВС – воздушное судно.

ГрК – Группа компаний.

ЗАКАЗЧИК – Группа компаний.

ИСПОЛНИТЕЛЬ.

КОНСОЛИДИРОВАННЫЙ БЮДЖЕТ – бюджет, агрегирующий данные всех нижележащих в финансовой структуре бюджетов.

РАБОЧАЯ ГРУППА – группа специалистов Заказчика и Исполнителя, совместно выполняющих работы по автоматизации бюджетного управления.

РГП – регулярные грузовые перевозки.

СЕ – структурная единица Группы компаний.

СИСТЕМА БЮДЖЕТНОГО УПРАВЛЕНИЯ – система управления компанией по центрам финансовой ответственности через бюджеты, позволяющая достигать поставленных целей путем наиболее эффективного использования ресурсов.

ТОиР – техническое обслуживание и ремонт.

ЦЕНТР ФИНАНСОВОЙ ОТВЕТСТВЕННОСТИ (ЦФО) – структурное подразделение (субъект бюджетного процесса), осуществляющее определенный набор хозяйственных операций, способное оказывать непосредственное воздействие на расходы и/или доходы от этих операций и отвечающее за планирование и исполнение своего бюджета.

ЧГП – чартерные грузовые перевозки.

Назначение документа

Устав проекта закрепляет организационную структуру проекта, регламент ведения проекта по автоматизации бюджетного управления для Группы компаний, а также содержит общее для Заказчика и Исполнителя понимание того, как решать проблемы в ходе проекта, как принимать решения в ситуации, когда рамки проекта, до его полного исполнения, невозможно точно определить.

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

Изменения документа

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

Цели проекта

Целью проекта является повышение эффективности управления ГрК посредством автоматизации системы бюджетного управления на основе автоматизированной системы.

Автоматизация системы бюджетирования позволит достичь следующие цели:

• повышение качества и оперативности процессов управления предприятием за счет:

• описания и формализации процессов бюджетного управления в документах «Техническое задание» и «Пояснительная записка к техническому проекту»;

• создание единой информационной среды для процессов бюджетирования и управленческой отчетности;

• обеспечение руководства заказчика оперативной информацией о выполнении среднесрочных целей компании заказчика, а именно – соотнесение среднесрочных целей и показателей бюджета;

• формирование единого аналитического пространства, обеспечивающего обработку управленческой информации.

Критерием достижения целей проекта является:

• наличие разработанных и согласованных Заказчиком документов по каждой стадии проекта, описанных в разделе 0;

• наличие качественных и количественных характеристик работающей системы:

• в системе осуществляются формирование и анализ исполнения, а также корректировка планов и бюджетов по методологиям: «снизу вверх», «сверху вниз» и смешанная;

• в системе осуществляется формирование и анализ план-факт отчетности;

• в системе предусмотрена возможность создания моделей расчета показателей и автоматизация пересчета взаимосвязанных показателей;

• в системе предусмотрено формирование операционных, инвестиционных и финансовых бюджетов предприятий;

• в системе предусмотрено ведение истории изменения версий бюджетов;

• проведение опытной эксплуатации системы бюджетного управления за определенный приложением № 1 к договору № 89–03/08ORCON срок и с зафиксированными там же условиями проведения опытной эксплуатации.

Границы проекта

Логические рамки проекта

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

Логические рамки проекта устанавливают перечень подлежащих бюджетному управлению бизнес-процессов предприятия заказчика по следующим направлениям деятельности:

• Основная деятельность:

• чартерные грузовые перевозки;

• регулярные грузовые перевозки.

• Прочая деятельность:

• пассажирские перевозки;

• автомобильные перевозки;

• выполнение и организация ТОиР ВС;

• сдача в аренду/субаренду/лизинг;

• посреднические услуги;

• страховые услуги;

• образовательные услуги;

• прочие услуги.

• Инвестиционные проекты.

Структура центров финансовой ответственности

Финансовая структура ГрК сформирована по организационному принципу с выделением центров финансовой ответственности в управляющей компании.

В управляющей компании выделяются несколько центров, ответственных за формирование бюджетов по всей группе компаний и контроль исполнения данных бюджетов. В табл. 1 приведены ЦФО группы компаний.

Таблица 1. Перечень ЦФО предприятия заказчика

Функциональная схема бюджетов

Предполагается, что автоматизированная система бюджетирования должна включать в себя следующие бюджеты:

Функциональные бюджеты:

• Бюджеты продаж:

• бюджет продаж по ЧГП на АН-124-100;

• бюджет продаж по ЧГП на ИЛ-76ТД;

• бюджет продаж по ЧГП на ИЛ-76ТД 90ВД;

• бюджет продаж по субчартеру;

• бюджет продаж по РГП на БОИНГ-747;

• бюджет продаж по пассажирским перевозкам на ЯК-40;

• бюджет продаж по автомобильным перевозкам;

• бюджет продаж по выполнению и организации ТОиР ВС третьим лицам;

• бюджет продаж по сдаче в аренду/субаренду/лизинг третьим лицам;

• бюджет продаж по посредническим услугам третьим лицам;

• бюджет продаж по страховым услугам третьим лицам;

• бюджет продаж по образовательным услугам третьим лицам;

• бюджет продаж по прочим услугам третьим лицам.

• Бюджеты маркетинговых расходов:

• маркетинговый бюджет расходов.

• Бюджеты PR-расходов:

• PR-бюджет расходов.

• Бюджеты расходов на персонал:

• фонд оплаты труда СЕ ГрК (постоянная и переменная часть, налоги);

• социальный пакет (льготы и компенсации, предоставляемые сотрудникам сверх установленных трудовым законодательством);

• прочие расходы на персонал;

• займы сотрудникам;

• обучение персонала.

• бюджеты финансовой деятельности:

• бюджет кредитов и займов;

• бюджет финансовых вложений;

• план расходов на услуги банков и банковские %.

• Бюджеты проектной (социальной и инвестиционной) деятельности:

• бюджет доходов и расходов;

• бюджет движения денежных средств;

• баланс.

• Итоговые бюджеты:

• бюджет доходов и расходов;

• бюджет движения денежных средств;

• баланс.

• Вспомогательные бюджеты:

• бюджет операционных расходов (нормативы);

• курсы валют.

Финансовая консолидация

На финансовую консолидацию предъявляются следующие требования и накладываются ограничения:

• В консолидации участвуют плановые и фактические данные с такой же по глубине аналитикой, как при планировании в разрезе классификатора статей и аналитик.

• Консолидированная отчетность по группе компаний формируется агрегированием статей по центрам затрат.

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

• Консолидированная отчетность на уровне группы компаний формируется в валюте «Доллары США», притом что каждая структурная единица имеет возможность планировать некоторые бюджеты в своей локальной валюте.

Горизонты планирования и версионность данных

Бюджетное управление деятельностью группы компаний осуществляется по двум горизонтам:

• долгосрочное планирование – планирование на три года вперед с детализацией по годам;

• среднесрочное планирование – планирование на год с детализацией по месяцам с агрегацией данных по кварталам, нарастающим итогом с начала года и в целом на год.

В автоматизируемой бюджетной системе формируются бюджеты в трех версиях:

• плановой;

• фактической;

• прогнозной.

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

Плановая версия бюджетов на год поддерживает следующие варианты бюджетов:

• оптимистичный;

• пессимистичный;

• наиболее вероятный.

Поддержка регламента бюджетного процесса

Разрабатываемая система бюджетирования должна обеспечить следующие принципы формирования бюджетов:

• формирование бюджетов по принципам «снизу вверх» и «сверху вниз»;

• принцип последовательности планирования – процесс взаимоувязки и интеграции отдельных планов на период происходит последовательно во времени;

• принцип нормативного планирования;

• принцип сквозного планирования – выделение на всех уровнях управления предприятия отдельных функциональных бюджетов с учетом ограничений по степени агрегации;

• принцип декомпозиции – каждый бюджет более низкого уровня является детализацией бюджета более высокого уровня.

Регламент модели бюджетирования должен поддерживать схему согласования данных, которая включает в себя пять основных этапов:

1. Согласование промежуточных итогов бюджета доходов и расходов ГрК.

2. Согласование инвестиционного плана ГрК.

3. Согласование промежуточных итогов бюджета движения денежных средств ГрК и его утверждение.

4. Утверждение бюджета доходов и расходов ГрК на уровне Президента ГрК.

5. Утверждение ключевых показателей деятельности ГрК на уровне Президента ГрК.

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

Контроль и анализ

Контроль и анализ в системе бюджетирования будет осуществляться на всех уровнях иерархии финансовой структуры:

• план-факт анализ – абсолютное и относительное отклонение фактической версии бюджета от плановой;

• вертикальный анализ – абсолютное и относительное отклонение значения бюджетной статьи к общей сумме по статьям;

• временной анализ – абсолютное и относительное отклонение значения бюджетной статьи по периодам (сравнение текущего периода с предшествующими или сравнение предшествующих периодов между собой) и расчет накопительного итога.

Контроль, формирование фактических данных в бюджетной системе и анализ осуществляется со следующей периодичностью:

1. Отчет о доходах и расходах – ежемесячно.

2. Баланс – ежеквартально.

3. Отчет о движении денежных средств – ежемесячно. Для формирования фактических данных предусматривается детализация по неделям месяца.

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

Таким образом, формируются следующие аналитические отчеты:

• Форма план-факт анализа для консолидированных бюджетов группы компаний.

• Форма горизонтального анализа для консолидированных бюджетов группы компаний.

• Форма временного анализа для консолидированных бюджетов группы компаний.

• Форма анализа для функциональных и специфических бюджетов.

• Форма дополнительных показателей.

• Отчет по плановой производственной себестоимости.

• Отчет по плановой полной себестоимости.

• Форма выверки внутрихозяйственных расчетов.

Валюта

Каждая структурная единица имеет возможность планировать некоторые бюджеты в своей локальной валюте. Консолидированная отчетность на уровне Группы компаний формируется в валюте «Доллары США». В валюте «Доллары США» также планируются все функциональные и специальные бюджеты на уровне Группы компаний.

При формировании консолидированной отчетности используется два курса пересчета:

• при формировании БДР и БДДС – курс валюты, установленный в Группе компаний на год;

• при формировании баланса – курс валюты на отчетную дату формирования баланса.

Бюджеты, формируемые в управляющей компании для всей Группы компаний для исполнения, могут быть пересчитаны в валюту структурной единицы по курсу, установленному в Группе компаний на год.

Связь с учетными системами (импорт фактической информации)

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

В рамках данного проекта интеграция с учетными системами не осуществляется. Фактические данные формируются в системе вручную или путем загрузки из Microsoft Excel из форматов бюджетов, для которых осуществляется сбор фактических данных. Выполнение регламентных процедур по формированию фактических данных производится аналогично вводу данных при планировании.

В рамках проекта предусматривается загрузка фактических значений только по вновь спланированным периодам. Исторические данные по плановым и фактическим значениям статей не загружаются. Планирование в системе начинается с момента ее сдачи в опытную эксплуатацию.

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

Плановые и фактические значения исторических данных (до 2007 года) Заказчик заносит в систему самостоятельно по примеру проведенного тестирования (на этапе «Реализация») одним из способов:

• непосредственное внесение данных в систему;

• внесение данных в бюджеты, выгруженные в Microsoft Excel, с последующей загрузкой данных в систему из Microsoft Excel.

Формат исторических данных до 2007 года имеет такие же ограничения, как и данные 2007 года, используемые для проведения тестирования.

Средства реализации

Средством реализации системы бюджетирования выступает программный продукт Oracle Hyperion Planning – System 9.

Географические рамки

Реализация проекта осуществляется силами Исполнителя в Московском офисе управляющей компании ГрК.

Проектные риски

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

Таблица 2. Риски проекта

Временные рамки проекта

Временные рамки проекта определяются из временных рамок каждой стадии проекта, которые приведены в табл. 3.

Таблица 3. Временные рамки проекта

Организационная структура проекта

Схема организационной структуры на время реализации стадии «Анализ и постановка»

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

На рис. 1 приведена организационная структура проекта на время реализации проекта «Автоматизация бюджетного управления консолидированной бюджетной модели ГрК».

Рис. 1. Организационная структура проекта

Управление проектом

В состав координационного комитета входят координаторы и менеджеры проекта со стороны Заказчика и Исполнителя. Координаторы проекта имеют право решающего голоса; менеджеры – право совещательного голоса. Решение координационного комитета считается принятым, если за него проголосовали оба координатора проекта. По решению координационного комитета в него могут быть введены дополнительно сотрудники заказчика и исполнителя с правом совещательного голоса.

Координационный комитет выполняет следующие функции:

• разрабатывает стратегические планы работы рабочей группы;

• контролирует выполнение плана проекта по стадиям;

• принимает решение об изменении сроков, выделении дополнительных ресурсов и изменении состава работ по этапам проекта;

• утверждает планы работ (в случае изменения первоначального плана);

• утверждает результаты стадий проекта;

• принимает решение о замене ресурсов, в том числе и о замене менеджеров проекта;

• согласовывает приказы по предприятиям заказчика, касающиеся деятельности рабочей группы;

• приминает решение по проблемам проекта, которые не уполномочены решать менеджеры проекта со стороны заказчика и исполнителя.

Выполнение работ по проекту

Рабочая группа состоит из двух подгрупп: участников проектной команды со стороны Заказчика и участников проектной команды со стороны Исполнителя. Каждая из подгрупп управляется своим менеджером проекта.

Рабочая группа выполняет следующие функции:

• выполняет работы по проекту;

• принимает решения о выборе способов выполнения плановых работ, об изменении сроков и последовательности выполнения работ в рамках сроков и объемов работ по этапам проекта.

Задачи и функции участников координационного комитета и рабочей группы

Координационный комитет

Координатор проекта со стороны Заказчика

Координатор проекта. Выполняемые функции:

• контролирует выполнение условий договора Исполнителем;

• контролирует ход работ по проекту со стороны Заказчика;

• принимает решение об изменении сроков, выделении дополнительных ресурсов и изменении состава работ по этапам проекта со стороны Заказчика;

• утверждает планы работ (в случае изменения первоначального плана) со стороны Заказчика;

• утверждает проектные документы со стороны Заказчика;

• утверждает результаты стадий проекта со стороны Заказчика;

• разрешает конфликты между Заказчиком и Исполнителем, находящиеся вне рамок работы рабочей группы;

• обеспечивает условия работы для рабочей группы на территории Заказчика.

Координатор проекта со стороны Исполнителя

Координатор проекта. Выполняемые функции:

• контролирует выполнение условий договора Заказчиком;

• контролирует ход работ по проекту со стороны Исполнителя;

• организует выделение необходимых ресурсов со стороны Исполнителя;

• принимает решение об изменении сроков, выделении дополнительных ресурсов и изменении состава работ по этапам проекта со стороны Исполнителя;

• утверждает планы работ (в случае изменения первоначального плана) со стороны Исполнителя;

• утверждает проектные документы со стороны Исполнителя;

• утверждает результаты стадий проекта со стороны Исполнителя;

• организует составление и утверждение приказов по предприятию Исполнителя, касающиеся деятельности рабочей группы;

• разрешает конфликты между организациями Заказчика и Исполнителя, находящиеся вне рамок работы рабочей группы;

• обеспечивает условия работы для группы внедрения на территории Исполнителя.

Менеджер проекта со стороны Заказчика

Менеджер проекта. Выполняемые функции:

• занимается подбором сотрудников Заказчика для работ на проекте;

• осуществляет оперативное руководство сотрудниками Заказчика, занятыми на проекте, организует выполнение ими плановых заданий проекта;

• несет ответственность за квалификацию и качество работы сотрудников Заказчика;

• участвует в разработке планов работ и предлагает решения о внесении изменений в ход проекта;

• организует сбор информации по ходу проекта со стороны Заказчика;

участвует в предварительном обсуждении проектных документов (до обсуждения на координационном комитете);

• контролирует качество выполняемых работ по проекту;

• контролирует выполнение утвержденных планов-графиков работ;

• согласует результаты работ по этапам проекта;

• согласует совместимость проектных решений с требованиями бизнеса и возможностями учетных систем предприятий;

• согласует внутренние организационно-распорядительные документы по проекту.

Менеджер проекта со стороны Исполнителя

Менеджер проекта. Выполняемые функции:

• осуществляет оперативное руководство сотрудниками Исполнителя, занятыми на проекте, организует выполнение ими плановых заданий проекта;

• несет ответственность за квалификацию и качество работы сотрудников Исполнителя;

• разрабатывает и поддерживает в актуальном состоянии планы работ;

• организует сбор информации по ходу проекта;

• организует и проводит встречи рабочей группы;

• организует и проводит встречи координационного комитета;

• составляет отчеты по ходу проекта для координационного комитета;

• ведет протоколы собраний координационного комитета;

• готовит обоснования для изменения сроков, объемов работ, привлечения дополнительных ресурсов для координационного комитета;

• разрабатывает отчеты по этапам проекта.

Рабочая группа

Функциональные специалисты со стороны Заказчика

Функциональные специалисты, входящие в рабочую группу.

Данные участники рабочей группы выступают в качестве ключевых пользователей и консультантов по предметной и функциональной областям.

Выполняемые функции:

• предоставляют Исполнителю информацию о процессе бюджетирования на предприятии Заказчика;

• участвуют в проведении анализа предоставляемых данных по процессу бюджетирования на полноту, непротиворечивость и соответствие потребностям Заказчика;

• дают пояснения консультантам Исполнителя по бизнес-процессам на предприятии Заказчика в ходе обследования предприятия;

• участвуют в разработке и согласовании проектной документации;

• выполняют тестирование системы бюджетирования;

• выполняют текущие задания менеджера проекта со стороны Заказчика в рамках реализации проекта;

• отчитываются перед менеджером проекта со стороны Заказчика в части работ по своему направлению.

ИТ-специалисты Заказчика

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

• общая координация проекта со стороны управления информационными технологиями от ГрК;

• участвует в определении входных и выходных данных модели;

• участвует в анализе и определении технического решения автоматизации системы бюджетирования.

Консультанты со стороны Исполнителя

Консультанты. Выполняемые функции:

• производят обследование бизнес-процессов предприятия Заказчика;

• участвуют в разработке и согласовании проектной документации;

• проводят настройку программного продукта Oracle Hyperion Planning – System 9;

• замещают менеджера проекта со стороны Исполнителя в случае его отсутствия;

• выполняют текущие задания менеджера проекта со стороны Исполнителя в рамках реализации проекта.

ИТ-специалисты Исполнителя

ИТ-специалист.

Выполняемые функции:

• подготовка тестового и промышленного серверов для установки программного обеспечения;

• установка и настройка СУБД на тестовый и промышленный сервер;

• перенос системы с тестового сервера на промышленные сервера;

• тестирование и доработка системы после переноса на промышленные сервера;

• консультация проектной команды по вопросам СУБД.

Порядок проведения собраний проектной команды

Собрания координационного комитета

Цели и условия проведения собраний

Собрания координационного комитета проводятся с целью решения задач, описанных в разделе [0] настоящего устава.

Собрание координационного комитета проводится только в случае присутствия обоих координаторов проекта.

Частота и время проведения

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

Документирование решений координационного комитета

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

Собрания рабочей группы

Участие в собраниях рабочей группы

Собрания рабочей группы служат для распределения заданий ее участникам и информирования участников проекта о текущем состоянии дел. В собрании обязательно участвуют менеджеры проекта. Состав участников собраний определяется менеджерами проекта.

Частота и время проведения

Рабочая группа собирается в плановом режиме один раз в неделю. Собрания могут быть перенесены или отменены по взаимной договоренности менеджеров проекта.

Участники рабочей группы могут принимать участие в собрании в режиме телефонной конференции.

Порядок ведения проектной документации

Обязательная проектная документация

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

• план проекта;

• устав проекта;

• техническое задание;

• пояснительная записка к техническому заданию;

• руководство пользователя;

• руководство администратора;

• техническое описание настроек системы;

• журналы тестирования;

• протокол проведения опытной эксплуатации;

• акт приемки модели в промышленную эксплуатацию.

Правила именования, хранения и предоставления проектных документов

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

Версии выходных документов могут меняться лишь после обсуждения с менеджерами проекта. Участникам проектной команды обеспечивается неограниченный доступ к базе данных.

Лицам, не являющимся участниками проектной команды, доступ к проектным документам предоставляется только на основании решения координационного комитета.

Общий порядок запроса и предоставления информации

В ходе выполнения работ по проекту могут формироваться и направляться запросы на подразделения заказчика на предоставление документов и информации. Полномочиями направлять запросы обладает менеджер проекта со стороны Заказчика.

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

Менеджер проекта со стороны заказчика информирует координационный комитет обо всех случаях задержки в предоставлении информации на запрос сверх указанного срока и/или немотивированный отказ в предоставлении информации по запросу.

Процедура согласования

Согласование и утверждение проектных документов по внутренней процедуре Заказчика

Ответственность за согласование и утверждение проектных документов возлагается на менеджера проекта со стороны Заказчика.

Порядок процедуры:

1. Создание документа участником рабочей группы со стороны Заказчика.

2. Направление участником рабочей группы документа на согласование менеджеру проекта со стороны Заказчика.

3. Оценка и согласование документа менеджером проекта со стороны Заказчика. В случае несогласования документ возвращается на доработку участнику рабочей группы – инициатору документа с соответствующими замечаниями.

4. После согласования документа менеджером проекта со стороны Заказчика документ, при необходимости, направляется на согласование руководителям тех подразделений ГрК, чьи интересы и функционал затрагивает разработанный документ.

5. Список участников согласования со стороны подразделений ГрК определяет менеджер проекта со стороны Заказчика. Если документ не согласован, менеджер проекта со стороны Заказчика предпринимает следующие действия:

• организует встречу с участниками согласования для обсуждения спорных вопросов;

• возвращает документ на доработку Исполнителю;

• направляет документ на повторное согласование после внесения Исполнителем всех необходимых поправок.

6. Окончательное согласования и утверждение документа со стороны заказчика.

Согласование и утверждение проектных документов, исходящих от менеджера проекта со стороны Исполнителя

Порядок процедуры:

1. Создание документа участниками рабочей группы со стороны Исполнителя.

2. Менеджер проекта со стороны Исполнителя по электронной почте рассылает документ координатору и менеджеру проекта со стороны Заказчика.

3. Менеджер проекта со стороны Заказчика при необходимости направляет документ на согласование участникам рабочей группы со стороны Заказчика и руководителям тех подразделений ГрК, чьи интересы и функционал затрагивает разработанный документ.

4. Список участников согласования со стороны подразделений ГрК определяет менеджер проекта со стороны Заказчика.

5. В течение двух рабочих дней после получения документа участники согласования должны предоставить менеджеру проекта со стороны Заказчика свои замечания, либо подтвердить, что замечаний не имеют. Если документ не согласован, менеджер проекта со стороны Заказчика предпринимает следующие действия:

• организует встречу с участниками согласования для обсуждения спорных вопросов;

• возвращает документ на доработку исполнителю;

• направляет документ на повторное согласование после внесения Исполнителем всех необходимых поправок.

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

7. Окончательное согласования и утверждение документа со стороны менеджеров проекта.

8. Выгрузка согласованного и утвержденного проектного документа менеджером проекта со стороны Исполнителя в «Проектный офис» на основе сетевого хранилища Заказчика.

Окончательные версии проектных документов передаются на согласование координаторам проекта.

Составление и корректировка планов работ

Первоначальный план работ утверждается в документе «План проекта». Вопросы изменения сроков завершения этапов проекта и привлечения дополнительных ресурсов решает координационный комитет. При этом утверждается измененная версия плана проекта.

Контроль и отчетность по исполнению планов

По результатам исполнения планов работ для обеспечения контроля и регулирования деятельности участников проекта составляются отчеты о текущем состоянии работ.

Менеджеры проекта организуют регулярный контроль исполнения планов работ и на ежедневной основе проводят мониторинг хода выполнения работ по проекту:

участники рабочей группы со стороны Заказчика отчитываются менеджеру проекта со стороны Заказчика в рабочем порядке – не реже одного раза в неделю, в форме отчета (с использованием средств электронной передачи данных);

участники рабочей группы со стороны Исполнителя отчитываются менеджеру проекта со стороны Исполнителя в рабочем порядке.

Менеджер проекта со стороны Исполнителя организует встречу «Статус Проекта» с участниками проектной команды со стороны Исполнителя и Заказчика – не реже одного раза в неделю.

Менеджер проекта со стороны Исполнителя подготавливает, согласовывает с менеджером проекта со стороны Заказчика, и, после согласования, рассылает координаторам проекта отчет о состоянии дел на проекте (отчет менеджера проекта). В отчете указываются текущие задачи проекта, статус их выполнения, прогноз сроков завершения для незавершенных задач, а также проблемы проекта и меры по их преодолению. Отчет предоставляется не реже чем раз в две недели в первый рабочий день недели, до 18 часов дня.

5. Пример тендерного задания

Введение

Информация о компании Проект

Группа планирует внедрить систему Oracle Hyperion Financial Management (далее Oracle HFM) для поддержки процесса подготовки консолидированной финансовой и управленческой отчетности.

Задачи проекта:

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

• Автоматизация процесса сверки внутригрупповых оборотов и остатков.

• Автоматизация расчетов и формирования трансформационных и консолидационных поправок.

• Автоматизация процесса консолидации.

• Автоматизация процесса ведения вспомогательных учетных регистров.

• Автоматизация контрольных процедур в бизнес-процессе формирования консолидированной финансовой и управленческой отчетности.

• Автоматизация формирования отчетов.

Основные условия

Процесс выбора подрядчика и начало работ

Структура и формат Предложения

Предложение должно содержать следующие обязательные разделы:

• Описание объема работ.

• Описание этапов проекта и временных рамок проекта (подробный план работ).

• Матрица ответственности между консультантом и Компанией в привязке к плану работ по проекту.

• Описание организации проекта и требований к проектной команде со стороны консультанта и Компании.

• Финансовые условия.

• Квалификация консультанта (резюме специалистов, опыт проектов).

• Дополнительная информация о консультанте с кратким описанием опыта реализации аналогичных проектов в России и за рубежом и роли предлагаемых членов проектной команды в этих проектах.

Объем работ

1. Виды консолидированной отчетности, входящие в объем работ:

1) Ежеквартальная консолидированная финансовая отчетность в соответствии с МСФО.

2) Ежемесячная консолидированная управленческая отчетность в соответствии с внутренними потребностями руководства группы.

3) Консолидированный годовой бизнес-план группы в формате управленческой отчетности, составляемый ежегодно и обновляемый на второе полугодие.

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

5) Текущий стратегический бизнес-план группы на 10 лет в формате управленческой отчетности.

Необходимо отдельно выделить время и бюджет проекта для каждого вида отчетности.

2. Основные функциональные требования, реализуемые в рамках данного проекта:

1) Ввод данных. Должна быть реализована возможность ввода данных вручную и автоматической загрузки данных в систему Oracle HFM из других бухгалтерских программ и MS Excel. Ввод данных будет происходить как непосредственно на местах в дочерних предприятиях, так и в головной организации. Приблизительное количество записей для консолидации на каждом объекте консолидации – 3000–5000. Данный показатель приводится только для проведения оценки объема работ и не может быть использован как ограничение по проекту.

2) Трансформационные корректировки отчетности объектов консолидации (в среднем 20–50 на каждый объект). Стандартные корректировки должны быть автоматизированы. Кроме того, система должна позволять проводить ручные корректировки.

3) Консолидация. Группа насчитывает более 100 дочерних предприятий, являющихся объектами консолидации. Система должна обеспечивать неограниченное или достаточно большое (более 50) количество многоуровневых консолидационных структур, использующих общие объекты консолидации, с возможностью раздельного внесения трансформационных и консолидацион-ных корректировок и пересчета в различные валюты. Система должна также обеспечивать распределение обязанностей по консолидации различных уровней одной консолидационной структуры по разным ответственным лицам, имеющим удаленный доступ к системе.

4) Консолидационные корректировки (в среднем 10–20 в каждой структуре консолидации на каждом уровне). Стандартные корректировки должны быть автоматизированы. Кроме того, система должна позволять проводить ручные корректировки.

5) Сверка внутригрупповых оборотов и остатков. Система должна формировать отчет расхождений для любого объекта консолидации или для подконсолидации.

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

7) Отчетные формы. Система должна формировать заданный набор электронных настраиваемых отчетов и выходных печатных форм в формате MS Excel и MS Word.

8) Концепция полномочий доступа к данным. Система должна обеспечивать индивидуально распределенный настраиваемый доступ к данным с разделением на ввод и чтение, по объектам и уровням консолидации, по набору доступных отчетов и по правам на утверждение.

9) Система должна сопровождаться документацией, достаточной для эксплуатации и сопровождения системы, включая руководство по инсталляции системы, администрированию, руководство администратора приложения, руководство пользователя, описание архитектуры и настроек системы, а также модели данных.

3. Обучение. Компания предполагает проведение консультантом, как минимум, двух больших сессий обучения непосредственно для конечных пользователей, проведенных проектной командой. При этом предполагается участие в обучении до 3 специалистов от каждого объекта консолидации и сегментов, образующих подконсолидации. Кроме этого, предполагается обучение специалистов Генеральной Дирекции Группы в количестве 20–25 человек, а также обучение администраторов системы в количестве четырех человек.

4. Тестирование. Вся необходимая для конечных пользователей функциональность по вводу информации должна быть протестирована до начала обучения. Функциональность консолидации должна быть протестирована к 31.12.2008. Интеграционное тестирование пилотного проекта должно базироваться на результатах первого квартала + апрель месяц 2009 года и плановых данных за 2009 г.

5. Загрузка исторических данных. В систему должны быть загружены данные финансовой и управленческой отчетности, а также годовых бизнес-планов группы за все периоды, начиная с 1 января 2007 года до первого периода фактической эксплуатации системы для каждого вида данных. Загрузка должна производиться автоматически по согласованному алгоритму из применяемых в настоящее время в группе финансовых моделей в формате MS Excel.

6. ИТ: Просьба в данном разделе описать требования вашего предложения к ИТ-инфраструктуре:

1) Предложения по общей архитектуре системы (состав необходимых программных компонент).

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

3) Количество необходимых лицензий.

4) Необходимое оборудование.

5) Требуемый штат сотрудников ИТ для поддержания системы, требуемая квалификация сотрудников.

6) Требования к администрированию базы данных Oracle.

7. Более подробно требования к единой системе отчетности в приложении 1.

Этапы и сроки проекта

Проект будет состоять из следующих основных этапов:

1. Разработка методологии консолидации[33].

2. Установка системы.

3. Настройка системы.

4. Загрузка исторических данных.

5. Обучение.

6. Пилотный проект.

7. Продуктивная эксплуатация.

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

В предложении следует четко раскрыть ответственность консультанта и компании на каждой стадии проекта. При необходимости – подробно расшифровать.

Контрольные сроки

Компания требует соблюдения следующих контрольных сроков проекта:

1. Начало проекта: 21.07.2008.

2. Окончание стадии «Разработка методологии консолидации»: 31.08.2008.

3. Система спроектирована, настроена и протестирована: 30.11.2008.

4. Подготовлено и проведено обучение конечных пользователей: 31.01.2009.

5. Запуск пилотного проекта:

1) подготовка консолидированной финансовой отчетности;

2) по МСФО за первый квартал 2009 + апрель 2009 31.05.2009.

6. Продуктивная эксплуатация:

1) подготовка консолидированной финансовой отчетности;

2) по МСФО за май 2009 20.06.2009.

Требования к консультанту

• Опыт внедрения систем консолидации, в особенности Oracle HFM.

• Знание и опыт в консолидации и проектировании систем.

• Технические навыки настройки систем Oracle HFM. Опыт управления крупномасштабными проектами.

Привлечение субподрядчиков должно быть согласовано с Компанией.

Договорные и юридические требования

Финансовые условия, стоимость работ

Компания предполагает производить оплату работ по фиксированной цене по окончании каждого этапа.

Консультанту необходимо предоставить:

• расчет трудозатрат по проекту с указанием ставки каждого консультанта, продолжительности работ, общей стоимости;

• расчет средней ставки одного консультанта в час.

Конфиденциальность

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

Дополнительные затраты

Компания не берет на себя никаких обязательств по оплате любых дополнительных расходов, возникших у консультанта в ходе подготовки и предоставлении предложения на данный запрос.

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

• Полное наименование. Юридический адрес.

• Коды ОКПО, ИНН.

• Фактический адрес, телефон.

Контакты

• Для предоставления предложений, а также общих вопросов.

• По вопросам ИТ.

• По вопросам, касающимся процессов планирования и отчетности.

Предложение должно быть предоставлено не позднее 01.07.2008 на русском языке, в конверте (почтовый адрес Компании), а также в электронном виде на следующие адреса (электронный адрес).

Библиография

1. David P. Norton. Organizing to Create Value. BSC Online Member's Briefing, April 2002.

2. Gerry Johnson and Kevan Scholes. Exploring Corporate Strategy, 5th ed. (London: Prentice-Hall Europe, 1999), 10.

3. Jack M. Keen. The Courage to Tout Intangibles. EarthWeb.com, June 1, 1999, from web site.

4. RBC Capital Markets Corp «SaaS Primer – An Emerging Asset Class».

5. Гарри Беквит. Продавая незримое.

6. Глобальный обзор KPMG LLP, Скотт Паркер, Глава финансового управления.

7. Исследования The Hacket Group, Answerlink.

8. Майкл Ковени, Деннис Гэнстер, Брайн Хартлен, Дейв Кинг. Стратегический разрыв. Технологии воплощения корпоративной стратегии в жизнь. М.: Альпина Бизнес Букс, 2004.

9. Николаев В. И., Брук В. М. Системотехника: методы и приложения.

10. Николас Карр. Невежество толпы.

11. Роберт Каплан, Дэвид Нортон. Отдел управления стратегией, HBR, Январь, 2006.

12. Субботин А. В. Управление портфелем ИТ-проектов.

13. ГОСТ Р 50.1.031-2001 «Терминологический словарь».

14. Кейс, № 2 (6) 2007 ст. «Фортуна финансиста».

15. Кейс № 3 (7) 2007.

16. Кейс № 1 (8) 2008.

Нормативные ссылки

1. Док. 1. ГОСТ 24.703-85 «Типовые проектные решения в АСУ. Основные положения».

2. Док. 2. РД IDEF0-2000. «Методология функционального моделирования IDEF0».

3. Док. 3. ГОСТ Р ИСО 9001–2001 «Системы менеджмента качества. Требования».

4. Док. 4. ГОСТ Р ИСО/МЭК 12207 «Процессы жизненного цикла программных средств».

5. Док. 5. Oracle Method. Application Implementation Method (AIM) 3.0 Handbook.

6. Док. 6. Oracle Method. Application Implementation Process and Task Reference.

7. Док. 7. ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания».

8. Док. 8. РД 50-680-88 «Методические указания. Автоматизированные системы. Основные положения».

9. Док. 9. ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы».

10. Док. 10. РД 50–34.698-90 «Автоматизированные системы. Требования к содержанию документов».

11. Док. 11. ГОСТ 24.103-84 «Автоматизированные системы. Основные положения».

12. Док. 12. «Системотехника АСУП. Общие вопросы и понятия» (КОРУС Консалтинг, 2004).

13. Док. 13. «Process Classification Framework» APQC International Benchmarking Clearinghouse.

14. Док. 14. ГОСТ 34.603-92 «Виды испытаний автоматизированных систем».

15. Док. 15. ГОСТ 24.104-85 «Автоматизированные системы. Общие требования».

16. ГОСТ 24 серии «Единая система стандартов автоматизированных систем управления».

17. ГОСТ 34 серии «Информационная технология. Комплекс стандартов на автоматизированные системы».

18. Требования стандарта ISO 9001 «Quality management systems. Requirements».

19. ГОСТ Р ИСО/МЭК 12207 «Процессы жизненного цикла программных средств».

20. Методики реализации приложений Oracle AIM.

21. Методологии функционального моделирования IDEF0.

notes

Примечания

1

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

2

Lee Geishecker and Nigel Rayner, Corporate Performance Management, 1.

3

Gerry Johnson and Kevan Scholes, Exploring Corporate Strategy, 5th ed. (London: Prentice-Hall Europe, 1999), 10.

4

Ковени М., Гэнстер Д., Хартлен Б., Кин Д. Стратегический разрыв, 2004.

5

Конечно, с учетом глобальных кризисных реалий 2009 года, эту цитату можно подвергать большим сомнениям. Лично я в своей консалтинговой компании перестал публиковать целевые показатели многолетнего планирования. Но! Кризис – это проверка стойкости для каждого бизнесмена. Поэтому долгосрочная стратегия у меня есть. А для всех моих сотрудников сегодня горизонт стратегического планирования сократился до одного календарного года.

6

Субботин А. В. Управление портфелем ИТ-проектов.

www.pmpractice.ru/knowledgebase/publications/?id=252.

7

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

8

ССП – это механизм последовательного доведения до персонала стратегических целей компании и контроль их достижения через так называемые ключевые показатели эффективности (КПЭ), в английском варианте – Key Performance Indicator (KPI), которые являются измерителями достижимости целей, а также характеристиками эффективности бизнес-процессов и работы каждого отдельного сотрудника.

9

Балансировка показателей ССП осуществляется на основе причинно-следственных связей, установленных в стратегической карте. Балансировка проводится между показателями различных проекций, различных временных горизонтов, а также между показателями результатов и факторов их достижения. Все показатели ССП через цепь причинно-следственных связей должны быть согласованы с финансовыми показателями // Эконика. Корпоративный журнал, № 18, 2005.

10

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

11

Журнал «Кейс». № 7. 2007.

12

Центр финансового учета (ЦФУ) – структурное подразделение, которое ведет учет установленных для него показателей доходов и/или расходов, но не отвечает за их величину (из Положения о финансовой структуре).

13

SADT (Structured Analysis and Design Technique – методология структурного анализа и проектирования) – методология, разработанная, чтобы облегчить описание и понимание искусственных систем, попадающих в разряд средней сложности.

14

I) Отчет о ПУ, II) ПДДС, III) Баланс.

15

Компания основана в 1997 году как ОАО «Отечественные лекарства». В настоящий момент в ее состав входят ОАО «Валента Фармацевтика», ОАО «Новосибхимфарм» и ОАО «Красфарма».

16

CRM – корпоративная информационная система, предназначенная для улучшения обслуживания клиентов путем сохранения информации о клиентах и истории взаимоотношений с ними, установления и улучшения бизнес-процедур на основе сохраненной информации и последующей оценки их эффективности.

17

Метаданные в общем случае – это данные, характеризующие или поясняющие другие данные. Например, значение «123456» само по себе недостаточно выразительно. А если значению «123456» сопоставлено достаточно выразительное имя «почтовый индекс» (что уже является метаданными), в этом контексте значение «123456» более осмысленно – можно извлечь информацию о местоположении адресата, имеющего данный почтовый индекс.

18

Журнал «Кейс», № 8, февраль 2007.

19

Московское отделение PMI – некоммерческая организация, чья цель – разделять опыт, знания и навыки Менеджеров проектов – членов отделения; развивать профессионализм в управлении проектами через программы сертификации (CAPM, PMP); добиваться признания и высокой оценки профессии «Менеджер проекта» в России. www.pmi.ru.

20

План проектирования итерационно детализируется на каждой стадии.

21

ERP, CRM, учетные системы и т. п.

22

Юлия Вольт.

23

Гарри Беквит. «Продавая незримое».

24

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

25

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

26

CPM – Corporate Performance Management – системы управления корпоративной эффективностью, минимальный перечень функциональности которых включает: стратегическое, бюджетное управление, оперативное и сценарное планирование, управленческий анализ, финансовая консолидация.

27

Майкл Ковени, Деннис Гэнстер, Брайн Хартлен, Дейв Кинг. Стратегический разрыв. Технологии воплощения корпоративной стратегии в жизнь. М.: Альпина Бизнес Букс, 2004.

28

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

29

Глобальный обзор KPMG LLP, Скотт Паркер, глава финансового управления.

30

Статья «Фортуна финансиста», Кейс, № 2, 2007.

31

Предмет целеполагания – инструмент, с помощью которого предполагается достичь цели, например: АСУ.

32

АСУ, как любая другая организационно-техническая система, является искусственной, то есть созданной человеком по его желанию.

33

Методологическая часть должна быть разработана собственными силами или с привлечением на субподряде аудиторской фирмы большой четверки.

Table of Contents

Дмитрий Геннадьевич Слиньков Управленческий учет: постановка и применение

1. Введение

1.1. Наши эксперты

1.2. Структура Руководства пользователя

1.3. Что такое управленческий учет?

1.4. Анализ разных подходов к внедрению УУ

2. Управленческое планирование

2.1. Стратегическое управление

2.2. Как связать стратегию с бюджетом

2.3. Бюджетное управление

2.4. Сценарное планирование

2.5. Проектное и инвестиционное планирование

2.6. Консолидация финансовой информации

2.7. Контроль и анализ

Трендовый анализ

Сопоставление данных разных версий

Сопоставление данных по разным объектам

Анализ «что будет, если…»

Анализ показателей эффективности

2.8. Финансовая модель данных

2.9. Подводные камни бюджетирования

Бюджет по бухгалтерским принципам

Бюджет заявок

Бюджет виртуального кошелька

Как избегать таких ошибок?

2.10. Управленческое планирование на примере фабрики валенок

Стратегическое управление

Сценарное планирование

Бюджетное управление

Контроль и анализ

Два вида бюджета – годовой и оперативный

Скользящее бюджетирование

3. Постановка УУ

3.1. Разработка политики УУ

3.2. Постановка планирования

Стратегические сессии

Постановка бюджетного управления

3.3. Постановка оперативного учета

Проектирование бизнес-функций

Проектирование бизнес-процессов

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

Процедуры масштабирования

Центр компетенции и методологии

Центр обработки данных

Дополнительные сведения к постановке оперативного учета

4. Технологическая поддержка управленческого учета

4.1. Введение в комплексные системы класса ERP

Разработка справочников. Несколько советов

Заведение новой товарной единицы

Основные справочники

Ввод данных

Одна или несколько

Отчет

Ликбез по многомерным базам данных

4.2. Классификация систем обеспечения УУ

4.3. Подходы к выбору программного приложения

Разрабатывать или внедрять готовое

Большая или маленькая

«Тяжелая» или «легкая»

Комплексная или сервисы

Контрольный пример

Запасной план

4.4. Выбор поставщика услуг по внедрению приложения

Большой, но дорогой

Конфиденциальность

Интерес консультанта

Пилотные проекты

Референтный визит

Команда

4.5. Как подготовиться к внедрению системы управленческого учета

Проверка боем

СМК

Администратор

Мотивационная программа

4.6. Методология внедрения

Подход к созданию АСУП. Описание методики

Классификация функций АСУП

Стадии ЖЦ АСУП

Особые замечания и советы

Зависимость необходимости в автоматизации от зрелости компании

4.7. Устав проекта

Управление проектом

Порядок проведения собраний проектной команды

Порядок ведения проектной документации

Процедуры согласования

Контроль и отчетность по исполнению планов

4.8. Как правильно вести проект внедрения системы УУ, или Подводные камни внедрения

Работа над ошибками

Ранжирование проблем

Нагрузочное тестирование

Разделение сред разработки и эксплуатации

Проблемы отношений с исполнителем

ТЗ – как договор

ИТ-проект среди других бизнес-проектов

Проектные риски

Ошибки консультанта vs ошибки разработчика

Забавный случай

4.9. Особенности автоматизации стратегического управления

Все тот же Balanced Scorecard

«Деревья надо знать по именам»[22]

И другие официальные features

Почем и как у других?

4.10. Современные тенденции развития ПО для бизнеса

Основные понятия

Проприетарное vs свободное ПО

«ПО как услуга»

Примеры «ПО как услуга» – Adaptive Planning

Пример «свободного ПО» – Palo Server

Основные поставщики ПО «по запросу»

5. Развитие УУ

5.1. Как рассчитать совокупную стоимость владения системой УУ

Затраты на проект. Их тьма

Возврат инвестиций

5.2. Теория жизненного цикла систем

5.3. МСФО и управленческий учет

Связь управленческого учета и МСФО

Практические пути получения международной отчетности

Альтернативные мнения

Примеры перекладки отчетности

5.4. Роль финансового директора во внедрении и развитии УУ, или «Последние дни» CFO

5.5. Что бы мы сделали по-другому

Приложения

1. Руководство по целеполаганию

Область применения

Определения

Назначение целеполагания

Принципы целеполагания

Общие рекомендации по целеполаганию

Формат определения целей

Связь целей компании, процессов и проектов

Использование целей в проектах

2. Положение о финансовой структуре

Структура центров финансовой ответственности

Полномочия и ответственность

Целевые показатели и показатели эффективности

3. Программа и методика испытаний

4. Устав проекта

Общие сведения

Границы проекта

Финансовая консолидация

Средства реализации

Географические рамки

Проектные риски

Временные рамки проекта

Организационная структура проекта

Управление проектом

Выполнение работ по проекту

Задачи и функции участников координационного комитета и рабочей группы

Порядок проведения собраний проектной команды

Порядок ведения проектной документации

5. Пример тендерного задания

Введение

Объем работ

Этапы и сроки проекта

Требования к консультанту

Договорные и юридические требования

Контакты

Библиография

Нормативные ссылки

Примечания

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33