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

АНО ВПО «Региональный финансово-экономический институт» УПРАВЛЕНЧЕСКИЙ УЧЕТ (Четвертая лекция) ___________________________ http://elearning.rfei.ru СОДЕРЖАНИЕ РАЗДЕЛ 1. ТЕХНОЛОГИЧЕСКАЯ ПОДДЕРЖКА УПРАВЛЕНЧЕСКОГО УЧЕТА (ПРОДОЛЖЕНИЕ)........................3 Глава 1.1 Устав проекта.................................................................. 3 Глава 1.2. Как правильно вести проект внедрения системы управленческого учета, или подводные камни внедрения..........5 Глава 1.3. Особенности автоматизации стратегического управления..................................................................................... 14 Глава 1.4. Современные тенденции развития ПО для бизнеса.19 РАЗДЕЛ 2. РАЗВИТИЕ УПРАВЛЕНЧЕСКОГО УЧЕТА................32 Глава 2.1. Как рассчитать совокупную стоимость владения системой управленческого учета.................................................32 Глава 2.2. Теория жизненного цикла систем..............................44 Глава 2.3. Международные стандарты финансовой отчетности и управленческий учет................................................................. 48 Глава 2.4. Роль финансового директора во внедрении и развитии управленческого учета, или «Последние дни» CFO. 57 Глава 2.5. Что бы мы сделали по-другому..................................62 2 2 РАЗДЕЛ 1. ТЕХНОЛОГИЧЕСКАЯ ПОДДЕРЖКА УПРАВЛЕНЧЕСКОГО УЧЕТА (ПРОДОЛЖЕНИЕ) Глава 1.1 Устав проекта Устав проекта закрепляет организационную структуру, регламент его ведения, а также содержит общее для заказчика и исполнителя понимание того, как решать проблемы в ходе проекта и как принимать решения, если до полного исполнения проекта невозможно определить его рамки (см. пример устава проекта — приложение 3). Порядок внесения изменений в устав проекта указывается в первом разделе устава. Здесь же прописываются цели проекта и критерии их достижения. Второй раздел устанавливает рамки проекта. Можно выделить логические, технические, географические и временные рамки, а также проектные риски: • Логические рамки охватывают направления деятельности компании, которые подлежат автоматизации. Это основной блок, который касается планируемых работ по проекту. Возможно, здесь стоит подробно описать структуру деятельности каждого подразделения; процессы, появляющиеся или меняющиеся в ходе проекта. • Географические рамки — место осуществления внедрения (название компании или филиала, указание региона). • Временные рамки проекта определяются, исходя из временных рамок каждой стадии проекта, которые приведены в разрезе дат, состава работ и результата. • Средство реализации целей проекта — это название внедряемых бизнес-приложений и название проектируемой АСУП. • Проектные риски. Несомненно, в ходе проекта могут возникнуть критические ситуации. Поэтому в уставе прописываются предполагаемые риски, а также меры, необходимые для их минимизации и предотвращения. 3 3 Третий раздел касается организационной структуры проекта. На время реализации проекта сотрудники заказчика и исполнителя составляют проектную команду, в обязанности которой входит выполнение работ по проектированию системы. Проектная команда делится на координационный комитет и рабочую группу. Управление проектом В состав координационного комитета входят координаторы и менеджеры проекта со стороны заказчика и исполнителя. Как правило, координаторы имеют право решающего голоса, а менеджеры — совещательного голоса. Решение координационного комитета считается принятым в случае, если за него проголосовали оба координатора. Функции координационного комитета и рабочей группы необходимо перечислить. Затем они максимально детализируются и определяются ответственные лица. Порядок проведения собраний проектной команды Собрания проводятся на уровне координационного комитета и рабочей группы. Периодичность их проведения, цели и документированные решения определяются в данном пункте. Порядок ведения проектной документации Мы говорили о необходимости бюрократизации процесса внедрения, которая в дальнейшем поможет разобраться в трудных ситуациях. К проектной документации в соответствии с утвержденным планом работ относятся документы, чье наличие является необходимым условием завершения проекта: • план проекта; • устав проекта; • техническое задание; • пояснительная записка к техническому заданию; • руководство пользователя; • руководство администратора; • техническое описание настроек системы; • журналы тестирования; 4 4 • протокол проведения опытной эксплуатации; • акт приемки системы в промышленную эксплуатацию. Вся текущая проектная документация должна храниться в специальной базе данных. Отдельно оговаривается доступ к этим документам, а также условия внесения в них изменений. Процедуры согласования Рассматриваются два варианта согласования — со стороны заказчика и исполнителя. Описывая процедуру согласования и утверждения проектных документов, не стоит забывать, что разрабатываемый функционал может касаться и других подразделений компании, чье участие в процессе согласования также необходимо пояснить. Порядок согласования прописывается с учетом иерархии внутри проектной группы и с привлечением руководителей затрагиваемых проектом подразделений. Контроль и отчетность по исполнению планов По результатам исполнения планов работ формируются отчеты о текущем состоянии работ. Менеджеры проекта могут отслеживать состояние проекта на регулярной основе, проводя мониторинг выполнения работ. В этом пункте необходимо указать структуру и частоту предоставления отчетов. В отчете координатору указываются: • текущие задачи проекта; • статус их выполнения; • прогноз сроков завершения для незавершенных задач; • проблемы проекта и меры по их преодолению. Устав принимается на самой первой стадии проекта. Организационные решения, закрепленные в уставе (такие как выделение рабочей группы, создание координационного комитета и т. п.), необходимо «узаконить» приказом по предприятию. Глава 1.2. Как правильно вести проект внедрения системы управленческого учета, или подводные камни внедрения Работа над ошибками Вы определили, как подготовиться к внедрению; выбрали методологию проектирования; у вас родился устав, организованы координационный комитет и рабочая группа. И вот происходит 5 5 самое интересное — внедрение. Обычно самыми оптимистичными являются первые стадии проекта. Всем понятны их предназначение и результаты: обследование и системное проектирование. Определенное замешательство возникает при демонстрации прототипа, во время приемочных испытаний. Но основные проблемы проекта возникают на стадии опытной эксплуатации, потому что это реальная проверка системы в жизни. Здесь главное — не забыть о бюрократизации. Управление инцидентами, ошибками, дополнительными разработками — достаточно большой объем информации, без систематизации которой нельзя добиться окончательного результата в виде внедренной системы. Ошибки желательно классифицировать по их типам: 1) технические — ошибки системы, когда от нее ожидается один функционал, а реализован другой или этот функционал не работает, хотя он есть в документации; 2) настроечные ошибки — когда в техническом задании описан функционал, а на проверке его нет; 3) ошибки последствия — когда из-за того, что не устранена одна из ошибок первого или второго типов, вы не можете протестировать правильность функционирования той или иной функции. Пример. В системе не работает функция начисления бонусов, поэтому вы не можете определить работоспособность функции «калькуляция себестоимости услуг», то есть она работает, но выдает неправильный результат. Изначально вторая «ошибка» регистрируется как «настроечная». Затем анализ «неправильных» результатов калькуляции себестоимости услуг показывает, что данную функцию необходимо протестировать после того, как будет исправлена ошибка начисления бонусов. 6 6 Все ошибки изначально регистрируются как «настроечные» и только после тщательного анализа могут быть окончательно классифицированы. Почему надо разделять ошибки? Техническое задание на 60-70% состоит из описания, как система будет работать в принципе, на 30% — из описания разработок. Если речь идет о разрабатываемых элементах, отличия в ошибках нет; если о работоспособности системы, приходится констатировать неправильную интерпретацию консультантом работы системы при таких настройках. Природа таких ошибок и инцидентов разная. С неработоспособностью системы (все без исключения приложения всегда содержат «баги») разбирается вендор, поэтому на нее довольно сложно повлиять. Ее решение зависит от оперативности работы технической поддержки вендора. Если он не решает их оперативно, значит, надо ждать периода обновления (нового релиза системы), что сказывается на сроке проекта. Ошибки, возникшие по вине консультанта, устраняются самим консультантом. Ранжирование проблем Проблемы в журнале надо ранжировать по степени критичности. Из-за высококритичных проблем система не может дальше использоваться, или компания в принципе не сможет в ней работать. Мы предлагаем выделять следующие уровни критичности проблем: • критичная для бизнеса; • критичная для работоспособности системы; • критичная для работы отдельного участка; • низкий уровень критичности (интерфейс, алфавитный поиск, неудобства). Неудобства могут не соответствовать ТЗ, но ошибки все равно не будут высоко критичны. Хотя иногда неудобства выражаются в том, что на работу в системе сотрудник тратит больше времени, чем если бы он это делал в удобном интерфейсе. Время слишком дорого для него и для компании, чтобы не называть данную проблему критичной для деятельности как минимум отдельного участка. 7 7 Журналы необходимо регулярно администрировать. Их должно вести ответственное лицо в каждом подразделении. В журнале отмечается тип ошибки и степень ее критичности. Координационный совет должен периодически просматривать журналы — в дальнейшем это поможет принимать систему. Нагрузочное тестирование Организационные проблемы часто приводят к реальным проблемам. Многие забывают о нагрузочном тестировании — воспроизведении во внедряемой системе (точнее — в программной платформе, которая выбрана для будущей системы) предполагаемого режима работы. Нагрузочное тестирование для любого инженера — превышение стандартной нагрузки. ПРИМЕР Настроили учетную систему для молокозавода. Настройка системы осуществлялась в административном корпусе; было проведено нагрузочное тестирование, причем довольно успешное. Но, во-первых, в самый последний момент добавили к классификаторам «забытый» аналитический признак. Во-вторых, начали разворачивать систему не только в административном корпусе, но и на производстве, которое располагалось через дорогу от главного здания. ИТдепартамент решал вопрос, как соединить здания. Первый вариант – радиорелейная связь. Второй – протянуть провод по воздуху. Третий вариант – пустить оптоволокно под землей, чтобы предприятие раз и навсегда было в единой сети. Запускаться надо было срочно, самое дешевое и простое решение – протянуть провод. Но добавленная в последний момент аналитика значительно увеличила объем обрабатываемых данных (любое движение документа сопровождалось вводом нового аналитического признака). Это на 25% увеличило объем обрабатываемой информации. Таким образом, нагрузочное тестирование, прошедшее до того момента, когда потребовалось связать две эксплуатационные площадки, было де-факто проведено не в соответствии с реальными эксплуатационными условиями функционирования 8 8 системы. В данной ситуации следовало прокладывать оптоволокно, что не было заложено в проект. В итоге сроки выросли. Чтобы не останавливать работу, заказы вводились в операторском режиме: за день собирался проект заказов и передавался в главное здание, где операторы все вносили вручную. Часто для нагрузочного тестирования используются программы-роботы, которые имитируют большой объем данных и большое количество документов, вводимых большим количеством пользователей. Если вы — действительно растущая компания, необходимо понять, как ваша система будет вести себя хотя бы в течение трех лет. Три года — жизненный цикл, в течение которого практически полностью обновляется функционал любого бизнес-приложения. Необходимо предположить, сколько пользователей у вас появится за это время. Допустим, вы не мечтаете расшириться до более 2000 человек, но вводите 4000. Аналогичный алгоритм применяем для прогнозирования количества операций: у вас сейчас такой-то оборот, вы планируете его на столько-то увеличить, следовательно, и количество операций увеличится на такую же величину. Результатом может быть не только падение работоспособности, но и ограничение в «железном виде». То есть серверы могут просто не выдержать эксплуатацию в подобном масштабе. В этом случае можно запускаться, но надо помнить, что через год придется докупить дисков, серверов и прочее. Разделение сред разработки и эксплуатации Вам необходимо позаботиться о том, чтобы с самого начала разделить версию системы в стадии разработки и эксплуатируемую. Кроме того, следует жестко регламентировать переход от одной версии к другой. К сожалению, не во всех системах такое возможно. Есть системы, которые для этого совершенно не предназначены. Поэтому задумайтесь: сможете ли вы работать в подобной системе? Если разработки ведутся в рабочей версии, не получится отследить, кто отвечает за неправильные введенные 9 9 данные: возникла проблема по вине пользователей, системы или разработчиков. Есть четыре уровня настройки бизнес-приложения: 1) исходное приложение (в поставляемом виде); 2) версия приложения с настроенными классификаторами и опциями; 3) версия приложения с дополнительными разработками; 4) рабочая версия, в которой пользователи работают. Обычно по мере разработок и развития системы версии три и четыре опережают по богатству функциональности рабочую версию. Но такой подход применим не ко всем бизнес-приложениям. Многие приложения класса СРМ не подходят для ведения разработок (это конструктор, идеологически не подразумевающий доработки). В подобных ситуациях целесообразно провести регламентацию работы пользователей (например, по времени). Действия разработчиков должны жестко протоколироваться, потому что проблемы могут быть фатальными: неправильно обновленная система легко уничтожит труд тысячи пользователей за огромный период времени, подорвав доверие к проекту, системе и идее управленческого учета в принципе. Вы платите консультантам не только и не столько за абсолютное знание. Вы платите за те знания, которыми они обзавелись на других проектах. Плюс — за усилия, которые они затрачивают, чтобы разрешить любые проблемы вашего проекта. Разделять системы нужно и в целях соблюдения конфиденциальности. Не стоит позволять рабочей группе и консультантам работать с вашими реальными данными. Консультанты должны представить свое видение, как они будут обращаться с информацией. Разработки ведутся на неполной версии данных; реальные цифры, показатели и значения вносятся не их силами, а вашими собственными. Проблемы отношений с исполнителем Вроде бы все ошибки на проектах заключались в том, что какие-то вещи, описанные в этой книге, не соблюдались. Но бывает 1 10 и по-другому. Например, готово ТЗ, но в ходе реализации системы и ее настройки у заказчика возникает новая потребность. Причем речь идет не о спонсоре или менеджере проекта, а о представителе среднего звена. Многие проектные проблемы строятся на мелочах. Случается, что линейный менеджер просит у консультанта новую функциональность, совсем небольшую, допустим, новый отчет. Консультант, естественно, ссылается на ТЗ. Тогда линейный менеджер припоминает, что консультант просрочил сдачу одной функциональности, а это дает право насчитать пени. В итоге консультант соглашается на разработку и за два дня пишет код, чтобы новый отчет появился. Речь не идет о воровстве — это типичная для проекта договоренность, в ней нет никакого криминала. Консультант сдает отчет заказчику, заказчик доволен. Но потом выясняется, что другим менеджерам такой отчет тоже нужен, все начинают им радостно пользоваться. Наступает стадия опытной эксплуатации, и именно на этом отчете происходят ошибки, потому что писался он впопыхах. Отчет становится самым популярным. Консультант бросается исправлять эту ошибку, забывая про другие. Теперь помножьте эту ситуацию на несколько раз. Данный пример — упрощенный. Речь может идти не просто об отчете, а о иной функциональности, которая порождает целую цепочку новых разработок, ошибок и разбирательств. Часто смешивают две разные вещи — управление изменениями и управление сроками. В обмен на нерегламентируемые изменения закрывают глаза на сроки. И тогда проект «плывет» на многие годы. Бывают ситуации, когда консультанты на свой страх и риск начинают работы из следующей стадии, в то время как текущая еще не завершена. Но вдруг возникает проблема с приемкой текущих операций. В итоге, все, что консультант сделал «авансом», может «сгореть». Консультанты требуют деньги за работы, выполненные заранее, но формально прежняя стадия еще не завершена и никто никому ничего не должен. Упомянутый здесь подводный камень внедрения называется «панибратское отношение с исполнителем». 1 11 ТЗ — как договор С ТЗ надо поступать, как с договором: если возникают новые условия, заключайте дополнительное соглашение. Доработки должны проходить все фазы обычного внедрения, просто это будут микрофазы. Если изменение критично для всего функционала в целом, придется переделать ТЗ. А переделка — это дополнительные траты. Но лучше переделать, чем закрывать глаза. Самая большая проблема проектов — снижение уровня бюрократизации, когда что-то делается «на честном слове». Казалось бы, слова генерального незыблемы, и вдруг на следующее утро его снимают и назначают нового. Менеджерам проекта необходимо следить за сроками, объемами и бюджетами. Если полностью следовать методологии, проблем возникнуть не должно. Но в реальности чего только не бывает. Сговоры и политические нюансы зачастую играют не последнюю роль. Статистика показывает: 80% успеха проекта — политические, 20% — методологические. Политика — это воля, дипломатия и умение добиваться поставленной цели с учетом интересов всех сторон. ИТ-проект среди других бизнес-проектов Порой значимость проекта недооценена, и директор может принять решение об изменениях в бизнесе. Например, внедрение осуществляется в холдинге, который образуют: авиакомпания, кейтеринговая, ремонтная фирма и др. Собственнику нужна единая система, чтобы управлять этими разнопрофильными бизнесами. Выполнив жесткие сроки, консультанты готовы запустить проект. И тут директор меняет структуру компании: продает пару бизнесов или объединяет несколько компаний в одну. Он не рассматривал проект внедрения системы как фактор, влияющий на бизнес. Однако проект внедрения АСУП может быть не менее важен, чем любой другой бизнес-проект, важность которого легко разрушить, недооценив ИТ-проект. Проектные риски Стороны осознают риски, которые могут возникнуть при реализации проекта, и в связи с этим договариваются о принятии 2 1 12 необходимых мер, чтобы предотвратить риски или уменьшить их влияние на проект. Перечень основных рисков и мероприятия по их минимизации представлены в табл. 1.1. Таблица 1.1. Риски проекта № Описание 1 Руководство ГК может делегировать исполнение задачи автоматизации бюджетного управления конкретным сотрудникам и исключить себя из участия в проекте, но быть одним из основных заказчиков системы 2 Ключевые сотрудники заказчика могут быть недоступны, когда необходимо, по причинам, связанным с исполнением прямых должностных обязанностей, отпусков, болезней и др., что приведет к затягиванию работ на проекте 3 В ходе проекта могут возникнуть потребности в увеличении рамок проекта Меры Представлять результаты проекта руководству ГК и согласовывать принципиальные моменты. Вовлекать в проект руководство ГК Осуществлять замену сотрудников на равных по профессиональным навыкам и знаниям предметной области Заключить дополнительный договор по оказанию услуг по дополнительным рамкам проекта Ошибки консультанта vs ошибки разработчика Часто ошибку в системе умелый консультант может «вывести» из проекта, так как это проблема вендора. Например, вы купили стиральную машину и позвали настройщика, который подключает ее к канализации и к крану. Технику вы купили сами (при покупке системы ситуация — аналогичная). Конечно, настройщик мог ее вам и перепродать, но на ней стоит знак производителя, и если что-то не будет работать, претензии надо предъявлять поставщику. Поэтому так важно разделять доработки неработоспособности системы и недоработки консультантов: даже суд встанет на сторону консультанта, если он докажет, что был не в курсе вендорской ошибки, из-за которой общий проект провалился. Если вы видите, что внедрений покупаемого вами бизнесприложения в компаниях, близких вашей, не было, вы вправе 3 1 13 требовать от вендора подписать соглашение, по которому в случае неудовлетворенности заказчика системой первый возвращает лицензии. Потому что вендор не может отвечает за работоспособность своего приложения из-за отсутствия практики внедрения. А она обусловливается не только объемами и отраслью, но иногда и конкретным функционалом. Забавный случай Кассовая система всегда строится по принципу — что бы ни произошло, покупатель должен уйти из магазина с товаром. Если магазин не может выпустить покупателя и принять плату за товар, он выпускает без платы. На практике был такой забавный случай. Открывался один супермаркет и внедрялась его кассовая система. Первичное тестирование прошло отлично. Но одного не учли: запуск был намечен на 29 февраля. Наступает заветный день — торжественное открытие и ни одна касса не может пробить чек! Система просто не поддерживала високосный год. Руководство распорядилось выпустить всех покупателей с товарами бесплатно, и магазин быстро закрыли на инвентаризацию. Глава 1.3. Особенности автоматизации стратегического управления В разделе 1.1 «Стратегическое управление» мы рассказали о том, как за 14 дней прорваться через блокаду «некогда» и начать у себя внедрение стратегического управления, основанного на ключевых показателях результативности. Это «бумажный старт», у которого нет будущего без использования информационных технологий. Бухгалтерский учет можно вести без ИТ, но не стратегическое управление, ориентированное на требовательных и привыкших к комфорту топ-менеджеров. Итак, следующая фаза — фаза развития стратегической модели с параллельной 4 1 14 автоматизацией. Без последней раскидистое «дерево» стратегии становится неуправляемым, а значит, люди перестают верить в возможность внести свой вклад в стратегию компании. Обзор продуктов, предназначенных для построения системы стратегического управления (ССУ), достоин отдельной статьи. Главное здесь — понять, что нужно требовать от такого продукта. Важно запомнить: продукт, предназначенный для стратегического управления, внедряется и используется не так, как мы привыкли внедрять и использовать ИТ-системы (табл. 1.2). Таблица 1.2. Сравнение традиционных ИТ-систем (ERP, CRM, учетные системы и т.п.) и систем стратегического управления Традиционные ИТ-системы Система стратегического управления Автоматизируют то, чего нет и без чего ССУ не будет Экстремальная методика внедрения: настраиваются сразу, техническое задание сделать невозможно Автоматизируют то, что есть Классическая методика внедрения: настраиваются после обследования и постановки задачи в виде технического задания Предназначены для предоставления данных снизу вверх по иерархии управления Основные пользователи и генераторы отчетности – рядовые сотрудники Наоборот Основные пользователи и генераторы отчетности – то- и линейные менеджеры Обучение пользователей – в начале проекта, чтобы настраивать систему Система используется сразу, чтобы разрабатывать стратегию компании Обучение пользователей – в конце проекта на настроенной системе Система разрабатывается для того, чтобы ее использовать, например в учете Запуск – повод для акта сдачи системы Запуск – повод для приказа о начале проекта Все тот же Balanced Scorecard Сила этой популярной методологии не в ее содержимом, а в идее — посмотреть на организацию под разными, заранее 5 1 15 определенными, углами зрения. Однако, выискивая во множестве продуктов черты ССП, не забывайте, что продукт должен предоставлять вам не только классические перспективы взгляда на ваше стратегическое дерево, но и произвольные. И конечно, поддерживать другие распространенные методики. Даже если на момент выбора вы считаете себя пожизненным адептом Нортона и Каплана. Например, в качестве объектов планирования можно использовать не Цель, Стратегию, Тактику и Действие из BSC, а Цель, Затраты, Процессы и Результат из «Шесть Сигм». Стратегическая модель — не просто дерево. Его компоненты связаны между собой причинно-следственными связями. Выбираемый продукт может в любой момент времени «разворачивать» это дерево так, чтобы вы эти связи видели (в ССП — стратегические карты). Вспомним о том, что инструмент стратегического управления в первую очередь предназначен для структурирования хаотичного и неформализованного сознания руководителя в конкретные символы, причем без ограничений. Только обогащение математическими шаблонами и возможностью быстро посмотреть «что будет, если» или «в чем причина, если». Поэтому важно, чтобы ваш будущий инструмент поддерживал максимальную визуализацию стратегического дерева. На рис. 1.1 изображен пример любимой многими топменеджерами портальной технологии, которая позволяет видеть все ежедневно необходимые показатели деятельности на одном экране и «сверлить» их до глубинных слоев либо выходить на показатели, оказавшие на них влияние. Всем известно типичное желание директора, впервые садящегося за дорогой ноутбук: «Хочу большую красную кнопку!» Если вы про это знаете, почему не требуете от производителя выбираемого продукта? 6 1 16 Рис. 1.1. Удобство портальной технологии И другие официальные features ССУ – инструмент коллективной работы. Поэтому надо позаботиться, чтобы в ней можно было собирать хронологию общения между пользователями (пояснения, комментарии к показателям, вербальные оценки деятельности и т. п.). По той же причине (коллективизация) требуйте от производителя четкого разграничения прав доступа к информации. Стратегические карты, отдельные показатели, иерархии аналитических измерений должны быть привязаны к конкретным пользователям, ролям или группам. Скорее всего, вам понадобится связь с большим количеством разных систем, предоставляющих информацию о фактическом выполнении стратегии. Также не забываем об открытости и интегрируемости. Важной составляющей модели стратегического управления является не просто показатель «План/Факт», но так называемый «Приведенный» факт, показывающий, насколько тот или иной показатель выполняется. Во внимание принимается его абсолютное значение «Объем выработки сопутствующей продукции» и стратегический вес, процент важности для достижения стратегической цели. Не слушайте заверения поставщиков продукта в гибкости и «широчайших возможностях при создании любых отчетных 7 1 17 форм». Во-первых, пользовательские формы ввода = формы отчетности. Вы легко модифицируете их сами: попросите у демонстратора компьютер и попробуйте сделать это прямо на презентации. Во-вторых, набор предна-строенных отчетов показывает, насколько сам производитель «в теме», понимает, для чего он разрабатывает свой продукт. Джентльменским (то есть минимальным) набором готовых к употреблению отчетов ССУ должны стать: 1. План в Виде Диаграммы – с помощью диаграммы показывает «Результат» (были ли достигнуты компанией цели) либо «Продвижение» (насколько хорошо компания выполняет план) для каждого объекта плана. 2. Анализ Результатов – сравнение значений «действия» и результатов. 3. Вклад Подразделений – показывает вклад каждого подразделения в достижение общих целей. 4. Ответственность – отчет демонстрирует объекты плана по ответственным за их выполнение и статус достижения цели. 5. Влияние на План – для выбранных объектов показывает их влияние на общий план. 6. Категория – показывает все объекты плана, сгруппированные по свойствам категории. Например, отчет может воспроизводить формат Balanced Scorecard, который разбивает все объекты на четыре категории: финансы, потребители, внутренние бизнес-процессы, обучение и развитие. 7. Сценарии – сравнивает фактические результаты с несколькими сценариями. Почем и как у других? Приготовьтесь к тому, что оплата ПО и услуг консультантов потребует от вас инвестиций, сопоставимых со 100 000 долларов. Если вы решите сэкономить на консультантах, можете потратить эти деньги на стоимость рабочего времени сотрудников, самостоятельно обучающихся новым технологиям: а) информационным и б) управления. 8 1 18 Только не забудьте, что «стратегический план не приносит никакой новой информации, сам по себе он ничему вас не учит. Стратегия бездействует и только прикидывается всезнающей, в то время как тактика постоянно проходит испытание рынком» (Гарри Беквит «Продавая незримое»). Глава 1.4. Современные тенденции развития ПО для бизнеса Основные понятия Последние годы среди пользователей бизнес-приложений наметилось тяготение к восприятию ИТ как обыденных и доступных каждому услуг. Во многом это отражение «консьюмеризации» общества. Наверное, каждый желает, чтобы ему не пришлось звонить в какие бы то ни было службы поддержки с вопросами: «Почему не работает?» или «Как мне сделать вот это?» Программное обеспечение становится более доступным с точки зрения цены, скорости внедрения, простоты использования и стоимости владения. Все больше компаний по всему миру обращают сегодня внимание на «Свободное ПО», «ПО по требованию» или «ПО как услуга». Для начала определимся с трудно произносимым термином «проприетарное ПО». По сути, это бизнес-приложения, которые вы привыкли использовать. Они приобретаются за деньги и имеют закрытый программный код. Собственническое или проприетарное программное обеспечение (англ. proprietary software) – это несвободное программное обеспечение, не удовлетворяющее критериям свободы ПО. Правообладатель сохраняет за собой монополию на его использование, копирование и модификацию, полностью или в существенных моментах. Не следует путать с собственническим коммерческим программным обеспечением, которое может быть свободным. Предотвращение использования, копирования или модификации может достигаться правовыми или техническими средствами. Доступ к закрытому коду обычно имеют сотрудники компании-разработчика, но могут применяться и более гибкие 9 1 19 условия ограничения доступа, в которых предоставление исходного кода разрешено партнерам компании, техническим аудиторам или иным лицам в соответствии с политикой компании. Свободное программное обеспечение – программное обеспечение, в отношении которого пользователь обладает «четырьмя свободами»: запускать, изучать, распространять и улучшать программу. Согласно нынешнему законодательству большинства стран, программный продукт и его исходный код по умолчанию охраняются авторским правом, которое дает автору (или другому правообладателю, в частности организации-нанимателю – для служебных произведений или наследникам – для умерших авторов) полную власть над распространением и изменением программы, даже в случае если исходный код общедоступен для обозрения. Чтобы программное обеспечение стало свободным, его правообладатели должны дать пользователю все четыре вышеназванные свободы действия. Это достигается выпуском исходного кода программного обеспечения под одной из особого рода лицензий, называемых свободными лицензиями. При этом автор программы сохраняет свои авторские права. Свободное ПО может одновременно быть и коммерческим – существует множество бизнес-моделей, где не надо платить за каждую копию ПО. Например, платная сервисная поддержка или коммерческая лицензия для использования свободного кода в собственническом ПО. Подавляющее большинство открытых программ является одновременно свободными и наоборот, поскольку определения открытого и свободного программного обеспечения близки. Только удовлетворяющая всем принципам свободы программа может считаться свободной, то есть гарантированно открытой и доступной обществу. Нужно подчеркнуть, что эти принципы оговаривают доступность программ для всеобщего использования, критики и улучшения, но не связанные с их 2 20 распространением денежные отношения, в том числе не предполагают бесплатность. В англоязычных текстах возникают разночтения, поскольку слово «free» по-английски означает не только «свободное», но и «бесплатное» и нередко употребляется по отношению к бесплатному программному обеспечению, которое распространяется без взимания платы за использование. При этом оно недоступно для изменения сообществом, потому что его исходные тексты не опубликованы. Такое бесплатное ПО вовсе не является свободным. Наоборот, свободное ПО вполне можно распространять (и распространяют), взимая плату и одновременно соблюдая критерии свободы: каждому пользователю предоставляется право получить исходные тексты программ, изменять их и распространять далее. Всякое программное обеспечение, пользователям которого данное право не предоставляется, является несвободным — независимо от любых других условий. Во избежание путаницы повторим уже сказанное в «зеркальном» виде: противоположностью свободного программного обеспечения является собственническое (проприетарное) ПО, которое тоже может быть как коммерческим, так и бесплатным (freeware). SourceForge.net – один из самых больших в мире каталогов открытого программного обеспечения, значительная часть которого распространяется и как freeware. Дадим определение «ПО по запросу» и «ПО как услуга». On-demand [ПО по требованию] – термин, обозначающий программное обеспечение, распространяющееся на условиях аренды. Это ПО, размещенное на серверах производителя с возможностью удаленного доступа (обычно через Интернет, с помощью веб-браузера). После подписки на услугу клиент получает возможность использовать ПО в течение оговоренного периода времени. Данную модель распространения ПО начали использовать в западных странах в 1997-1998 годах. Доля ПО, распространяемого на условиях аренды, постоянно растет. 1 2 21 Такую модель продаж активно используют производители бизнес-систем. В первую очередь, CRM-систем и систем управления проектами, поскольку данная модель доступа к ПО позволяет контролировать территориально распределенных продавцов, консультантов и агентов без каких-либо затрат на организацию единого рабочего пространства. Серьезным преимуществом on-demand-систем является отсутствие ИТ-затрат. Так как система находится на стороне поставщика услуг, все работы, связанные с поддержкой оборудования и программного обеспечения в рабочем состоянии, выполняет поставщик услуг. Исчезают и затраты на серверное оборудование, сопутствующее программное обеспечение. Одним из факторов, значительно снижающих затраты на сопровождение, является автоматическое бесплатное обновление on-demand-систем. А ежегодные затраты на обновление версий обычных систем составляют в среднем не менее 15-40% от их стоимости. Как правило, on-demand-системы размещаются в крупных дата-центрах. В этом случае также начинают работать механизмы защиты данных самих дата-центров, значительно более серьезные, чем те, которые может себе позволить средняя компания. В случае размещения on-demand-системы в дата-центре обеспечивается лучшая непрерывность работы (достигает 99-99,8% времени). Также крупные дата-центры дают гарантии на сроки замены вышедшего из строя оборудования. В целом on-demand – это комплексная услуга, включающая как возможность использования ПО, так и все сопутствующие услуги по поддержке его работоспособности. Software as a service (SaaS) – программное обеспечение как услуга – модель предложения программного обеспечения потребителю, при которой поставщик разрабатывает вебприложение, размещает его и управляет им (самостоятельно либо через третьих лиц) с целью и возможностью использования заказчиками через Интернет. Заказчики платят не за владение 2 22 программным обеспечением как таковым, а за его использование (через API, доступный через веб и часто использующий вебслужбы). Близким к термину SaaS является on-demand (приложение по запросу). Принципиальным отличием модели SaaS от более ранних (hosted applications и application service provider (ASP)) является то, что приобретается именно услуга и интерфейс (пользовательский или программный), то есть некоторая функциональность без жесткой привязки к способу ее реализации. В модели SaaS: - приложение приспособлено для удаленного использования; - одним приложением пользуется несколько клиентов (приложение коммунально); - оплата взимается как ежемесячная абонентская плата или на основе объема транзакций; - поддержка приложения входит в состав оплаты; - модернизация приложения происходит плавно и прозрачно для клиентов. Проприетарное vs свободное ПО Описание, плюсы и минусы Поддержка. Разница в поддержке проприетарного и свободного ПО существенна, свободное ПО в этом плане выигрывает. В случае с поддержкой проприетарного ПО вы фактически платите за исправление багов разработчиков. А когда речь идет о сопровождении свободного ПО, вы действительно платите за его развитие. Обладая исходным кодом, вы можете самостоятельно исправлять все мелкие баги. Это гораздо проще и быстрее, чем писать письмо в службу сервисной поддержки, которая присвоит вашему запросу определенный код, и вы днями и ночами будете следить за статусом исполнения вашей проблемы. Потом получите нерадостное сообщение: «Да, действительно, это ошибка! Мы ее исправим в следующем релизе, который выйдет 3 2 23 через три месяца/в следующем году». С подобной картиной сталкивались многие. В силу большей легкости разработок в секторе свободного ПО его техподдержка легче и мобильнее. Потому что она идет именно за счет развития, в то время как для традиционной модели техподдержка означает сначала исправление ошибки, а потом уже развитие. Так как производитель не получает деньги за лицензии, платежи за поддержку для него – единственный источник дохода. И вы можете себе представить, насколько он вкладывается в развитие и озабочен тем, чтобы в случае обнаружения багов исправлять их, выпускать новые релизы и т. д. К тому же свободное ПО подразумевает сообщество, community. Например, adaptive planning предлагает два уровня поддержки своих программных продуктов. Первый, бесплатный – собственно поддержка через сообщество: пользователь может задать вопрос разработчикам бесплатной версии или на Интернет-форуме. Им это действительно интересно – это их детище. Начинаются споры и обсуждения, которые часто приводят к улучшению продукта и устранению его недостатков. Основные поставщики «свободного ПО» Основанные на технологиях с открытым исходным кодом, современные BI-инструменты оказываются совместимы с Linux, Apache, JBoss, а также с Perl, Python, Ruby, MySQL, PostgreSQL и т. д. Глобальная совместимость позволяет фактически любому ИТ-департаменту любой компании применять BI-инструменты с открытым исходным кодом. Понимая это, многие производители ПО и оборудования запустили инвестиционные проекты, цель которых – создать простые, состоящие из множества модулей BIинструменты с открытым исходным кодом при минимальной стоимости рабочего места. Это, в свою очередь, заставило малый и средний бизнес обратить внимание на рынок BI, ранее для него закрытый из-за высоких издержек. Mondrian – сервер с открытым исходным кодом, написанный на языке Java. Поддерживает язык запросов MDX 4 2 24 (многомерные выражения) и спецификации XML for Analysis и JOLAP. Mondrian может использовать различные источники данных (в том числе и SQL), умеет кешировать в памяти суммарные результаты. Ingres – коммерчески поддерживаемая открытая реляционная база данных. В начале 1970-х годов была создана как научно-исследовательский проект в Университете Калифорнии (США). Оригинальный код Ingres был доступен за минимальную плату под версией лицензии BSD. С тех пор, начиная с середины 1980-х годов, Ingres породил множество коммерческих баз данных, включая Sybase, Microsoft SQL Server, NonStop SQL и множество других. Ingres – один из наиболее влиятельных современных компьютерных научноисследовательских проектов. Своим появлением система с открытым исходным кодом JBoss перевернула рынок серверных приложений, вынуждая традиционных вендоров полностью менять свою продуктовую стратегию (пример – компания ВЕА) либо создавать альянсы по продвижению своих брендов (пример – альянс IBM и Oracle). Этот подход существенно снижает затраты на маркетинг и продажи, тем самым способствуя перераспределению бюджетов в пользу исследования и разработки новых продуктов. Вот далеко не полный перечень «свободных» продуктов: • Ubuntu Server & Desktop Edition; • Alfresco ECM & WCM; • Zimbra CS; • Sugar CRM; • Linux; • Palo-Server; • Spago BI. «ПО как услуга» Описание, плюсы и минусы Признаки ПО «по запросу»: 1. Приложение данного типа должно принадлежать одному или нескольким провайдерам, распространяться и управляться 5 2 25 исключительно ими: если продавец требует, чтобы его клиенты инсталлировали приложение в рамках своей ИТ-инфраструктуры, это не on-demand. Поставка on-demand предполагает, что продавец организует работу в удаленном режиме, а также привлекает третьих лиц для обеспечения доступа к приложению, его модернизации и поддержке ИТ-инфраструктуры и пользователей. 2. Поставщик предоставляет заказчику приложение, основанное на единых исходном коде и модели описания данных. Они всегда потребляются в режиме «один ко многим» всеми заключившими контракты клиентами. Последние могут применять расширения при использовании соответствующих конфигурационных инструментов, предоставляемых вендором, но без изменения основного исходного текста. В этом заключается отличие от традиционной модели хостинга приложений, когда поставщик поддерживает множественные прикладные коды, версии или настройки, неодинаковые для разных клиентов. 3. Оплата основывается на подписке (например, из расчета на одного пользователя или за ежемесячную плату) или на степени востребованности приложения (скажем, на числе выполненных за определенный период транзакций). Если предусмотрена покупка лицензий, это не on-demand и не SaaS. Сектор SaaS-провайдеров сейчас бурно растет, и многие компании, которые предоставляют данный сервис, уже вышли на биржу. Котировки компаний такого класса всегда росли быстрее рынка и NASDAQ. Это достаточно красноречивое доказательство того, что сектор SaaS действительно развивается. Ниже приведены преимущество SaaS для клиентов, поставщиков ПО и инвесторов. 6 2 26 Таблица 1.3. Преимущества модели SaaS Для клиента Быстро развертывается. Требует меньше инвестиций, внесенных авансом. Быстрее/легче развивать. Не требует ИТ-поддержки. Легко доступна через веббраузер. Низкие затраты на подключение. Заведомо легче выстраивать отношения с вендором. Возможность использования операционного бюджета для покупки. Для SaaS-поставщика Больше инструментов взаимодействия. Выше прозрачность прибыли. Подготовленность ПО для среднего бизнеса. Не очень сильное влияние на бизнес-программы по снижению цен. Заведомо легче выстраивать отношения с клиентами. Ниже требования по исследованию и разработкам. Более устойчивый рост. Прибыльнее. Для инвестора Видимая прибыль. Меньше подверженность колебаниям рынка. Легче моделировать и прогнозировать. Слабым местом Software As A Service является контроль нескольких сервис-провайдеров, выстраивание интеграции данных из двух разных задач. Может показаться, что проще обратиться к традиционной методике введения, построения информационно-системных компаний, чем заниматься «лоскутной» автоматизацией. На самом деле это не так. Компании, предоставляющие услуги в данной области, выбирают нишевые задачи, которые не нуждаются в тесной интеграции с другими задачами, как, например: расчет заработной платы, включая кадровую систему; управление обучением сотрудников; бюджетное управление. В большинстве фирм одним из компонентов бюджетного управления является бюджетное планирование на основании имеющихся данных за прошлые периоды. Оно хорошо укладывается в идеологию Software As A Services и не нуждается в ежедневной и точной интеграции с другими приложениями. Если необходим факт, то его достаточно выгрузить из системы и сохранить; нужен план – следует та же процедура. Локальные задачи легко решаются посредством сервисов, а глобальные, 7 2 27 связанные с охватом компании в целом и поддержкой информационных ресурсов, – с помощью серьезных ERPприложений. Общие признаки сервиса в том, что он выполняет достаточно ограниченную по отношению к функционалу предприятия задачу, не требует больших усилий по внедрению и замене, легко взаимодействует с другими сервисами. При этом взаимодействие между сервисами происходит без вмешательства ИТ-специалистов. Примеры «ПО как услуга» – Adaptive Planning Excel – это сервис для работы с электронными таблицами, но при ведении бюджетирования необходимо работать с многомерной, финансовой моделью предприятия в многопользовательском режиме с единой версией факта. Adaptive Planning сумела сделать такой продукт, который действительно легок в функциональном смысле и в процессе внедрения. Вся идеология компании Adaptive Planning нацелена на то, чтобы дать предприятиям среднего бизнеса простой в использовании и, что еще важнее, – во внедрении продукт бюджетного управления. Большим преимуществом Adaptive Planning является то, что в его состав входят так называемые мастера создания моделей. Мастер расскажет, что такое измерения, финансовая структура, предоставит уже предзаполненные формы ввода и т. п. Вы можете получить рекомендацию, как лучше сделать план счетов (статьи доходов и затрат) с учетом того, какие статьи доходов и затрат обычно используются другими фирмами. Вам остается буквально «расставить галочки». Пример «свободного ПО» — Palo Server Д. Новоселов: «Проблема заключается в том, что Excel как инструмент имеет два больших недостатка. Первый – нет «защиты от дурака», человека, который может что-то случайно разрушить. Второй – при работе в нескольких файлах с перекрестными ссылками при неправильном открытии или сбое 8 2 28 Excel ссылки между файлами разрушаются. Конечные итоги становятся неактуальными. И, конечно, тяжело работать с большими файлами: они могут неправильно сохраниться, медленно загружаются, может произойти любая неожиданность». Миссия Jedox – сделать Excel лучше. Тому, кто работает в финансовой сфере, не может не нравиться Excel. Jedox предлагает бесплатно скачать продукт под названием Palo-Server. Скачивание и установка системы Palo занимает несколько минут. Далее вы открываете привычный для вас Excel через ярлычок Palo Excel Add in (прим.: интересна разница между «addon» и «add-in». Add-on – это фактически новое приложение, выстроенное над основной программой; add-in – функциональное «встраивание» в основную программу, в данном случае – платформу, под названием Excel. Говоря иначе, это улучшение основной платформенной программы). Открыв таким образом Excel, вы заметите, что у вас появился еще один пункт меню верхнего уровня. В этом пункте пользователь может создать, например, модель или отчет. Плюсы такого приложения понятны и очевидны: • вы по-прежнему работаете в Excel; • ваша система – многопользовательская; • все данные хранятся в единой базе; • вам больше не придется заниматься кропотливым «сведением» десятков и сотен электронных таблиц в единую отчетную таблицу. Кроме того, программа внедряется за один-два месяца, что разительно отличается от длительных проектов автоматизации бюджетного управления. Тема open source сейчас настолько модная, что люди в погоне за трендом готовы объявить ее чуть ли не полной заменой всему, что было наработано ранее. Свою роль здесь сыграли идеологические факторы, проблема вен-дорозависимости и просто реклама. В будущем бизнес станет развиваться, используя 9 2 29 и свободное, и проприетарное ПО. Понятия вытеснения и конкурентной борьбы просто исчезнут. Если и будет борьба, то не на уничтожение, а на сосуществование. Многие производители проприетарного ПО используют сегодня популярность свободного ПО, чтобы легко и незатратно продвигать самих себя. Идея проста: во всемирную сеть выкладывается урезанная версия продукта, обладающая функциями, которые позволили бы поверить в то, что цельный продукт действительно достоин внимания. Надо разграничивать реальные open source бизнес-приложения и такие «приманки» для клиентов. Настоящее open source решение – это, например, SpagoBI, Pentaho, которые мало того что разрабатываются в режиме открытого ПО, так еще используют его разные компоненты и платформы. Сервисы или «большие системы»? В предыдущих главах мы размышляли, какой путь развития лучше – интегрированных систем, чье преимущество заключается в том, что она покрывает все, или развитие по принципу сервисов, когда на каждую задачу есть определенный сервис. Все идет к тому, что язык интеграции, передачи данных становится единым, и данные будут легко передаваться от сервиса к сервису или от сервиса к «большой» системе и т. п. По поводу open source... Кто же все-таки победит – проприетарные или свободные? С точки зрения бизнеса, подобная батальная лирика роли не играет. Гораздо важнее интересы дела. Это противопоставление искусственно, пока open source разработки не могут покрыть с достаточной долей надежности такой массив процессов организаций, какой обеспечивают традиционные системы. Open source зачастую имеет конкурентное преимущество лишь за счет своей бесплатности. В отношении будущего проприетарного и свободного ПО можно только делать прогнозы. На данный момент общая рекомендация такова. Проприетарной ERP-системой вы, конечно, не закроете сразу все необходимые участки. Если у вас «горит» 3 30 конкретная задача, смело решайте ее с помощью свободного ПО. Если же вы имеете референции о том, что продукт легко внедряется, то у вас просто не будет стартовых затрат. И, кроме того, вы набираетесь опыта в познании того, как технологии могут применяться на данном участке. Последнее справедливо так же и в адрес ПО как услуги. Если взять любую из линеек бизнес-приложений (мы их назвали «слоями регулярного менеджмента»), для каждой из них найдется и традиционное, и свободное ПО, и ПО «как услуга»: 1) бюджетирование; 2) управление финансами; 3) CRM; 4) управление логистикой; 5) управление производством; 6) управление персоналом; 7) управление неструктурированными данными; 8) управление электронным коммерческим документооборотом. Возможно, что проприетарное ПО в будущем формально станет свободным (есть замечательная книга Эрика Рэймонда «Собор и базар». Она дает ключ к пониманию того, откуда берется и как возникает свободное ПО; что его создают не какие-то сидящие в подвале самозванцы, а люди, способные работать для бизнеса, потому что они являются неким управляемым сообществом, а не одиночками.) – прецеденты уже есть. Microsoft давно действует по такому принципу, закрывая глаза на пиратские копии своего софта и открывая части ОС Windows для государственных и учебных учреждений. Главное, чтобы создатели традиционного ПО поняли ценность сервиса, а не хватались только за продажу лицензий. Чем больше будет появляться свободных производителей с хорошей поддержкой, тем быстрее упадут цены на проприетарное ПО, на лицензионную составляющую его стоимости. 1 3 31 РАЗДЕЛ 2. РАЗВИТИЕ УПРАВЛЕНЧЕСКОГО УЧЕТА Глава 2.1. Как рассчитать совокупную стоимость владения системой управленческого учета Зачем вообще необходимо знать эту цифру? Во-первых, чтобы понять, во сколько обойдется внедрение управленческого учета, и, во-вторых, чтобы определить отдачу от внедрения системы. Начинаем с самых простых, прямых компонентов владения системой. Они состоят из затрат: • на консалтинг; • на лицензии; • на обучение персонала; • на дополнительные разработки, если они выделены в условиях договора (обычно оговариваются отдельно, когда вас не устраивает изначальный функционал системы и вы хотите ее переработать под свои нужды). Кстати, это очень хороший пример того, как нужно разбивать проект на более мелкие проекты, так как если доработки действительно требуются, лучше заключить отдельный договор; • на сопровождение системы. Сопровождение системы, как правило, включает два компонента: подписку на обновления системы и сопровождение консалтинговой фирмой, которая в договорах прописывает его рамки. Вероятно, это будет выделенный Helpdesk или обращения по электронной почте. В любом случае вы сами должны принять решение – насколько вам необходима сторонняя помощь при эксплуатации системы. Подписка на обновления часто включает не просто изменения стандартного функционала и исправления неработающего, но и доработки, связанные с изменением законодательства в стране. Это, по большей части, касается бухгалтерского функционала, хотя такие фундаментальные изменения в учете, как необходимость прописать тот же номер ГТД (Грузовая таможенная декларация – письменное заявление установленной формы, которое подается таможенному органу и 2 3 32 содержит данные относительно товаров и транспортных средств, перемещаемых через таможенную границу, необходимые для их таможенного оформления или переоформления) во всех документах, в свое время привели к кардинальному изменению всех существующих в России ERP-систем. Но такое бывает редко, поэтому уровень абонентской платы необходимо выбирать самостоятельно. Главное – сопоставить все элементы затрат на систему. Неправильно говорить, что система стоит 5 млн долларов лишь потому, что консалтинг и лицензии вместе образуют такую сумму. ТСО имеет гораздо больше параметров. По истечении жизненного цикла системы (практически для любой системы равен трем годам, а для систем типа SAP – четыре-пять лет) вам придется задуматься о новой системе либо о новых, небольших системах, которые бы функционировали параллельно с большой. Если суммировать все единовременные инвестиции (единовременными их можно назвать с трудом, потому что любой проект длится как минимум год, а то и два-три), добавить стоимость поддержки, сопровождения и обновлений за три-пять лет, получится цифра, которая в совокупности с прямыми затратами даст итоговую стоимость на внедрение информационной системы. Это очень полезная цифра. Благодаря ей вы сможете оценить, были ли у вас ранее настолько масштабные проекты. Управленец вообще вправе сравнивать, что он хочет и с чем хочет, хоть со стоимостью своего коттеджа или автомобиля. Все зависит от того, какими ценностями он оперирует, как ему легче воспринять ту или иную сумму. Ведь в абсолютном эквиваленте 5 млн долларов – внушительная сумма. Предприятию, оборот которого даже 3 33 полмиллиарда, эта цифра может показаться большой. Но если это предприятие собирается на следующий год увеличить оборот до миллиарда, то без систематизации всех бизнес-процессов оно не сможет этого сделать. Придется идти на столь мощные инвестиции. Еще проект внедрения можно сравнить с инвестиционным проектом. Сопоставимы ли затраты на него с остальными типами инвестиционных проектов в вашей компании? Сравнивать надо не только с вашими привычными инвестиционными затратами, но и с тем эффектом, который вы ожидаете от этих проектов. Если за 5 млн построить новый цех, то с его помощью можно увеличить производство – вроде, эффект очевиден, а при внедрении системы эффект от вложенных средств неосязаем. Здесь мы касаемся очень скользкой темы – возврата инвестиций от внедрения информационной системы. Среди консультантов и продавцов программного обеспечения действует негласное правило: компания психологически не может потратить на оптимизацию управленческого учета больше одного процента от своего оборота. Приведем очень интересный пример, как один клиент при обороте, условно говоря, 150 млн, решился на автоматизацию, совокупная стоимость владения которой только по прямым затратам составляла около 3 млн (по идее должно было быть 1,5). Интрига заключалась в том, что на следующий год его оборот стал 500, а еще через год – 700 млн. Управленец этой компании (речь идет о крупном дистрибьюторе) просто хорошо осознавал свой рост; понимал, сколько внедрение стоит сегодня и сколько будет стоить завтра, и удачно выбрал момент для нормализации бизнес-процессов, потому что такой проект – это в конечном итоге изменение культуры и получение выгоды. Затраты на проект Существует теория трех видов затрат: 1. Прямые. 2. Косвенные. 3. Менеджерские затраты (самый сложный, но очень интересный вид). 4 3 34 Косвенными считаются затраты времени вашего персонала на внедрение. Прямые затраты на обучение – это зарплата учителю, а косвенные затраты на обучение – это зарплата, которую вы платите сотруднику, пока он учится. Конечно, вы можете возразить, что это несущественно – обучение становится его должностными обязанностями, – но в большинстве случаев с сотрудников, которые занимаются проектами, их текущие обязанности не снимаются. Если человек был загружен на 100%, с появлением системы – на 150-200%, то есть люди сидят вечерами, работают в выходные и т. д. Если вы им за это платите повременно, затраты становятся косвенными. Еще нужно учесть бонусы. Многие считают, что бонусы, заложенные в бюджет проекта, являются косвенными затратами. Но это самые что ни на есть прямые затраты на проект; оплата командировочных, связанных непосредственно с проектом, тоже относится к прямым затратам. Сотрудник занимает рабочее место и площадь, косвенные затраты по отношению к оплате его труда автоматически становятся косвенными затратами проекта. Есть еще затраты, вызванные организационными изменениями. Любые перестановки чреваты снижением эффективности труда. Дело в том, что внедрение оперативной части управленческого учета в 90% случаев не является жизнеобеспечивающим. Непосредственно у бизнеса нет потребности в новой системе управленческого учета. Это не автоматизация, например, складских операций или производства, когда процесс шел медленно из-за отсутствия автоматического планирования заказов. А внедрение ERP-системы в части производства положительно отразилось на эффективности, заказы стали обрабатываться быстрее, и этот эффект можно посчитать. Автоматизация управленческого учета – ненасущная задача, нужная управленцу, потому что его не устраивает процесс поступления к нему информации. Исполнители не заметят улучшения своих условий труда, скорее, наоборот. В 90% случаев происходит ухудшение условий труда, потому что, во-первых, нужно научиться работать в новой системе, и, во-вторых, 5 3 35 работать в ней, скорее всего, будет неудобно, потому что usability практически никогда не является целью проекта. Самые эффективные внедрения, самые быстрые и законченные, совершаются на системе с минимальными настройками, а уже потом начинаются мини-проекты по улучшению дружелюбности интерфейсов и т. д. Поэтому объективно возникают косвенные затраты, связанные с переходом на новую систему или на новую организационную структуру. Переходы чреваты задержками в работе, а это стоит денег. Прямыми являются затраты на аппаратное и инфраструктурное обеспечение. Прокладка новой сети, новых каналов – тоже прямые затраты на проект. Правда, иногда инфраструктурные затраты экономически нецелесообразно относить полностью на проект, потому что их благами пользуются даже те, кто в нем не участвуют. Прокладка оптоволоконного кабеля для всей компании не будет относиться исключительно к затратам проекта, хотя будет его непременным условием. Поэтому справедливо разнести такие затраты пропорционально – взять от стоимости прокладки оптоволокна отношение реальных пользователей системы к пользователям оптоволокна. Еще есть щепетильная тема лицензирования базового программного обеспечения (Windows, Office и т. п.). Ведь зачастую на предприятиях число компьютеров растет быстрее, чем количество лицензий на базовое программное обеспечение. В итоге внедрение большой системы сопровождается тотальным лицензированием. Здесь точно так же нельзя всю стоимость базового лицензирования объявлять прямыми затратами. А теперь о так называемых «менеджерских затратах». Например, вы управляете большой компанией, занимаетесь продажей мобильных телефонов, у вас начинается проект по автоматизации, и это совершенно новый проект. Вы, как управленец, отвлекаете часть своего собственного ресурса на то, чтобы внедрить у себя систему. Вместо того чтобы развивать бизнес, идти вперед, заключать новые соглашения, вы 6 3 36 занимаетесь несвойственной вам задачей, которая вам интересна как некий элемент инвентаризации ресурсов, – остановиться и посмотреть, «а что же у меня есть», встряхнуть организацию, найти возможных потенциальных лидеров (в проектах внедрения на первый план как раз выступают не начальники отделов, а их заместители или просто способные люди). Но несмотря на полезность проекта, вы можете прикинуть, сколько потеряете, не занимаясь основным бизнесом, а отвлекаясь на проект, – это те самые затраты третьего уровня. То же самое происходит при сопровождении внедренной системы. Создание HelpDesk – тоже несвойственная бизнесу функция, которая находится в подчинении департамента ИТ, а департамент ИТ выполняет множество других обязанностей. В итоге директор этого департамента подчиняется финансовому либо напрямую генеральному директору, и вся цепочка занимается несвойственными им прежде функциями. Это похоже на эффект энтропии, когда маленькая посторонняя деталь обрастает еще большими несвойственными для организации в целом вещами. Любой прецедент всегда существует по принципу снежного кома. Если вы отдаете предпочтение самостоятельному сопровождению системы, а не передаче функций HelpDesk на аутсорсинг, это выливается в косвенные затраты на зарплату, помещение и коммуникации, в затраты на менеджмент (людьми должен кто-то руководить). Для каждой компании эти затраты индивидуальны. Сейчас ИТ-обеспечение является ключевым для многих фирм – растущих и развивающихся. Но эксплуатация и развитие ИТ – не их ключевая компетенция, они не являются профессионалами в данном вопросе. Если компания все-таки выбирает путь самостоятельного развития системы (по разным причинам), то руководство должно отдавать себе отчет в том, что существуют еще менеджерские затраты. Очень многие компании, особенно в сфере услуг, консалтинге, знают, как увеличить свой оборот вдвое. Однако чтобы получить эти деньги, им нужно еще десять таких же сильных топ-менеджеров, а их найти трудно. Так становится понятно, чего стоит время менеджера. 7 3 37 Возврат инвестиций Чтобы получить представление, где играет роль эффективность, необходимо научиться ставить перед собой следующие вопросы. Каков денежный эквивалент знания о тенденциях изменения рыночных условий, если они меняются чаще, чем один раз в месяц? Сколько стоит информация, которую вы не получаете даже после внедрения системы управления ресурсами предприятия (ERP), CRM-системы и системы управления логистическими цепочками (Supply Chain Management, SCM)? Современная деловая литература и опыт подсказывают, что можно выделить, как минимум, шесть источников повышения корпоративной эффективности – шесть выгод внедрении СРМ-систем (СРМ – Corporate Performance Management – системы управления корпоративной эффективностью, минимальный перечень функциональности которых включает: стратегическое, бюджетное управление, оперативное и сценарное планирование, управленческий анализ, финансовая консолидация): 1. Увеличение деловой подвижности. Чем раньше будет получена достоверная информация, тем больше будет выбор. 2. Улучшение процесса планирования. Доступ ко всему массиву информации по заданной теме улучшает процесс планирования. 3. Улучшение процесса принятия решений. Этот процесс можно представить как вовремя доставленную информацию. Где производство построено на удовлетворении нужд сегодняшнего дня, там необходима и информация такого же качества. 4. Прибыль от фондового рынка. Рынки вознаграждают компании, которые пристально следят за своими деловыми операциями. Акционеры вознаграждают те компании, которые оправдывают их ожидания. 5. Улучшение корпоративной организации. Чем шире распространяются корпоративные знания, тем совершеннее становится организация. Пропаганда значения и понимания индивидуальных задач среди сотрудников существенным образом 8 3 38 повышает уровень корпоративной организованности. Термин для такого преимущества – «прибыль от управляемости» (return on management, ROM). 6. Объединение организации. Когда СРМ-система используется для привязки стратегии к тактике и измеримым результатам, организация начинает действовать слаженно – каждый работает на общие цели. Все руководители должны понимать эти шесть выгод в контексте их собственных организаций как минимальное требование при создании перечня показателей эффективности. Получив такой список, остается наполнить эти нематериальные преимущества реальными цифрами. Подсчет эффективности (и других нематериальных выгод) Каждому было бы интересно подсчитать доходы от эффективности при использовании СРМ-систем. Вопрос заключается в том, как это сделать. Ответ совсем не так очевиден. Данный раздел описывает четыре методики выражения в числовом эквиваленте нематериальных выгод. Это предполагаемая сумма прибыли, средняя ожидаемая сумма прибыли, прибыли от ERP (управления ресурсами предприятия) и конкурентное преимущество. Так как эти методы являются оценочными, кто-то может усомниться в корректности их результатов. Лучший способ разрешить сомнения –использовать классические подсчеты при проведении корреляций или определении вероятностей. Целью таких операций является общее понимание выгодности внедрения СРМ-системы. Предполагаемая сумма прибыли. Это одна из методик подсчета суммы прибыли. Она состоит в том, чтобы найти внутри организации проекты, которые приносят относительную ценность предложенному проекту. Следует использовать ROIанализ по определению суммы доходов от эффективности при использовании СРМ-систем. Например, организация инвестировала 300 000 долларов в создание системы управления продажами, и она сокращает процесс составления отчета с двух недель до режима реального 9 3 39 времени. Такая система управления сэкономила две недели. Условная сумма прибыли от более быстрого доступа к информации оценивается в 150 000 долларов в неделю или 300 000 за две недели. Точно так же закупаемая СРМ-система сэкономит три недели. Составление отчетов теперь займет одну неделю вместо трех (экономия – две недели), а прогнозирование займет одну неделю вместо двух (экономия – одна неделя). Доступ к коммерческой информации был улучшен на три недели при оценке управленческих программ на предполагаемую сумму прибыли в 450 000 долларов. Это оправданный и консервативный метод подсчета суммы прибыли, установленный корпоративной политикой и практикой независимо от планируемого проекта внедрения СРМ. Средняя ожидаемая сумма прибыли. Данный метод включает опрос людей, желающих получить прибыль от системы, о сумме этой прибыли. Преимущество состоит в том, что менеджеры обязаны решать, какие функции в частности будет выполнять СРМ-система. Их привлечение повысит вероятность принятия проекта и может раскрыть непредвиденные выгоды. Другой плюс этого метода – подсчеты основаны на информации тех самых сотрудников, которые лучше всего осведомлены об ожидаемой прибыли. Стандартный подсчет средней ожидаемой суммы прибыли приведен в табл. 2.1 и является одной из техник для подсчета дохода от эффективности. Таблица 2.1. Программа СРМ для бюджетирования Функция Управление материальнотехническим снабжением Закупки Функции казначейства Средняя ожидаемая сумма прибыли Потенциальная сумма прибыли $3млн $2 млн $2 млн 4 40 Вероятность Ожидаемая сумма 5% $150 000 10% 3% $200 000 $60 000 $410 000 Получение прибыли от управления ресурсами предприятия. Любая компания, вложившая деньги в систему управления ресурсами предприятия, имеет по-настоящему детальную информацию для этого проекта. Цель – вернуться к этой информации и определить, какие ожидавшиеся прибыли от проекта не были реализованы. Областями, где обнаруживается максимальное количество нереализованных прибылей, обычно являются информационная интеграция, составление отчетов и анализ. Несмотря на обещание ERP создать единое интегрированное хранилище данных, многие организации вынуждены сохранить некоторые ранние системы и отдельные программы. Сила СРМ-систем заключается в том, что они позволяют объединить вместе в корне различные источники данных и улучшают (если не предоставляют впервые эту возможность) процесс запроса данных и возможности по созданию отчетов при применении ERP. Поэтому новые СРМсистемы могут быть изначально наделены этими уже признанными и подсчитанными прибылями. Как и вычисление суммы ожидаемой прибыли, ERP-методики получения прибыли являются оправданным и консервативным методом подсчета, установленным корпоративной политикой и практикой независимо от начинаемого проекта. Конкурентное преимущество. Существуют два основных способа повысить конкурентное преимущество – снижение издержек и увеличение ассортимента. Любая аналитическая программа, которая дает лучшее понимание природы издержек, продукции или услуг, является стратегической и повышает конкурентное преимущество компании. Превратить расчет отдачи от инвестиций в конкурентное преимущество непросто, если смотреть на такие вещи, как вебсайты клиентов или на программы по управлению взаимоотношениями с клиентами. Необходимо выразить лояльность покупателя, увеличение доли рынка, улучшение процесса принятия решений и тому подобное в числовом эквиваленте. Во многих случаях даже компании, проводившие 1 4 41 серьезные деловые исследования, смогли найти материальные выгоды для покрытия только 40-80% предполагаемых расходов на проект. Если те нематериальные выгоды так хороши, чтобы оправдать оставшиеся миллионы, вложенные в ERP, они, безусловно, должны быть проанализированы СРМ-системами. Для понимания соответствующей связи суммы прибыли с конкурентным преимуществом миссия организации и ее стратегический план должны быть структурированы по общности и противоречивости взглядов, а также на предмет улучшенного реагирования. Имея эту информацию, руководители, ответственные за применение такого видения, должны определиться с ценой достижения поставленной цели. Это поможет понять связь инвестиций и стратегического видения организации, создать систему расчета суммы прибыли для бизнес-исследования. Преимущество данной операции заключается в дополнительном времени на покупку и применение новых управленческих систем; на понимание ценности инвестиций не только с точки зрения сбережения затрат. Их вклад поможет создать раздел эффективности в бизнесисследовании и дать дополнительное понимание в применении системы. Основная стратегическая выгода внедрения СРМ-систем заключается в том, что они объединяют организацию вокруг стратегического видения. Работа, посвященная ROI и бизнесисследованиям, среди управленцев высшего звена является началом достижения этой выгоды. Сразу оговоримся: управленческая система не нацелена на улучшение условий труда (условия труда улучшатся, но в процессе эксплуатации, когда люди поймут эффект работы в едином информационном пространстве). Все системы нацелены на обработку документов в местах их возникновения, поэтому на автоматизированных участках можно попробовать просчитать эффективность. Например, раньше заказ в среднем обрабатывался час, сейчас – 15 мин. Без автоматизации производства и проектной деятельности 2 4 42 управленец не будет получать нужную информацию. Вследствие этого вам нужно внедрить всю методологию MRP-I и II, в результате которых появится автоматизированное планирование производства, перепланирование, калькуляция, расчет узких мест, маршрутизация и т. д. Тогда производственникам становится действительно легче – они быстрее обрабатывают заказы, выполняют другие операции. Но бухгалтерии, например, станет сложнее – появятся дополнительные аналитические признаки, которые нужно регулярно вводить. Любой фактор, влияющий на эффективность, сразу обрастает несколькими субфакторами. Есть показатель «скорость обработки заказа»: раньше она составляла час, теперь – 15 мин. От этого есть прямой и косвенный эффекты. Прямой эффект – как минимум, увеличение зарплаты человека, занимающегося обработкой этих заказов (раньше он мог в день делать восемь заказов, теперь – 32). От него выстраивается цепочка косвенных воздействий: большее количество заказчиков можно привлечь в единицу времени, увеличивается лояльность заказчиков и т. д. Остается найти все измеряемые факторы и провести от них как можно больше таких «веточек». Это называется деревом стоимостных факторов. Даже когда «веточка» не исчисляется напрямую (например, если речь идет об измерении лояльности одного заказчика), эти пустые места заполняются экспертно: мы обращаемся непосредственно к директору по продажам: «Сколько стоит лояльность одного клиента?» Лояльный клиент – тот, кто продолжает делать заказы. Если он делает новые заказы, по объемам сопоставимые с заказами от новых клиентов, в эту графу можно запросто поставить сумму, затрачиваемую на продажи и поиск новых клиентов. Таким образом, лояльность тоже исчисляется деньгами. То же самое с лояльностью персонала: если ему удобно и приятно работать и он видит, что, используя эту систему, повышает свою компетенцию и ценность, это тоже чего-то стоит – затрат на поиск и обучение новых сотрудников (а также затрат на неизбежное в случае замены персонала падение эффективности). 3 4 43 Вообще, игра очень интересная и увлекательная, но на практике полностью такое дерево расписывать бесполезно. Чтобы обозначить эффект, не стоит его рассчитывать с точностью до копейки. Вывод: из всех этих показателей может сложиться цифра, вероятно, намного большая, чем сумма прямых, совокупных и менеджерских затрат; хотя вполне допустима и меньшая. Что делать, если меньше? Не расстраиваться. Это значит, что вы не все учли; что нечто может произойти в будущем и т. д., то есть ваше дерево неполное. Приобретение системы проходит через такую цепь принятия решений, когда ты все сравниваешь и балансируешь – брать или не брать? стоит, не стоит? крупная покупка, не крупная? В конечном счете выходишь на правильную рыночную стоимость своей новой системы. Глава 2.2. Теория жизненного цикла систем Жизненный цикл (ЖЦ) системы в общем смысле – это процесс создания, разработки, эксплуатации, поддержки и снятия с эксплуатации системы управления. Методика построения стадий жизненного цикла системы зависит от его концепции, то есть от модели. Наиболее подходящие модели ЖЦ в зависимости от типа бизнес-приложения: Каскадная (рис. 2.1) Каскадная модель ЖЦ используется, когда практически все исходные условия проекта известны: требуемая функциональность (приложение готово, существует, его «просто» нужно настроить под конкретное предприятие), временные рамки и «география» внедрения. Применяется при внедрении приложений класса ERP, CRM, СРМ, любых комплексных многофункциональных бизнесприложений. 4 44 Рис. 2.1. Схема каскадной концепции ЖЦ Инкрементная (рис. 2.2) В инкрементной модели требования разрабатываются изначально – один раз для всех очередей («конструкций») системы. Затем система вводится по очередям; каждая может развертываться и запускаться самостоятельно. Возможности системы (функции, площадки) реализуются как отдельные подсистемы. Полная функциональность системы появляется после запуска всех очередей. Применяется при внедрении приложений класса ERP, CRM, СРМ, любых комплексных многофункциональных бизнесприложений. Отличие от каскадной модели в том, что мы заранее не знаем один из двух параметров проекта – время или «географию». Кроме того, инкрементная модель ЖЦ применяется к серии проектов (часто называется программой). Каждый проект в отдельности выполняется согласно каскадной модели, а программа в целом – по инкрементной. То есть мы имеем дело с гибридной моделью ЖЦ проектирования АСУП. 5 4 45 Рис. 2.2. Схема инкрементной концепции ЖЦ Эволюционная (рис. 2.3) В эволюционной модели система эволюционирует – целиком проходит весь ЖЦ, но отдельными очередями, то есть пока запущен первый релиз, готовится второй (всей системы), за ним следующий и т. д. Требования к системе в целом постоянно меняются (нет возможности установить все сразу). Всякий раз она запускается целиком. Подсистем быть не может. 6 4 46 Рис. 2.3. Схема эволюционной модели ЖЦ Применяется при: • эксплуатации и развитии ERP-приложения или любого другого комплексного приложения; • разработке дополнительных функций эксплуатируемой АСУП; • разработке самостоятельных комплексных приложений. Знание теории ЖЦ поможет вам: 1) самостоятельно строить планы реализации вашей АСУП; 2) оценивать правильность методологических подходов, предлагаемых консультантами по внедрению той или иной бизнес-платформы; 3) подбирать для себя ту или иную модель ЖЦ системы в зависимости от того, какое приложение вы внедряете и каковы исходные условия проекта (программы). 7 4 47 Важно: при составлении договора на внедрение бизнесприложения(ний) прописать тип используемой модели ЖЦ, потому что модель – это отправная точка для оценки качества проекта. Глава 2.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 году в России принята и исполняется программа реформирования бухгалтерского учета в соответствии с МСФО. 8 4 48 В частности, с 2005 года все кредитные организации обязаны подготавливать отчетность в соответствии с нормами МСФО. Национальный совет по стандартам финансовой отчетности (Фонд НСФО) ведет работу по созданию комплекта национальных стандартов финансовой отчетности (СФО) с июня 2006 года. Фонд «Национальная организация по стандартам финансовой отчетности» считает, что общественно значимые организации должны готовить отчетность в соответствии с российскими стандартами финансовой отчетности (СФО). При условии сохранения существующего авторитета МСФО на международных рынках капитала СФО должны представлять собой перевод английского текста МСФО. Желательно одобрение перевода со стороны Совета по международным стандартам финансовой отчетности. Связь управленческого учета и МСФО В разделе «Политика управленческого учета» мы уже рассказывали о том, что многие (большинство!) предприятий в качестве стандарта УУ руководствуются принципами МСФО. Это разумно вдвойне: во-первых, не нужно ничего выдумывать – стандарты уже есть и хорошо описаны. Во-вторых, внедрив у себя УУ в формате международных стандартов, вы впоследствии сможете легко использовать накопленный опыт, чтобы регулярно составлять отчетность в соответствии с МСФО. Некоторые компании подходят к формированию международной отчетности, как к ведению бухгалтерской. Выделяется отдельное подразделение – один-два или более человек, которые занимаются перекладкой уже сформированной РСБУ-отчетности. Если фирма не собирается использовать МСФО как инструмент управления, этого недостаточно. В идеале принципы ведения УУ должны быть выстроены по МСФО. Это позволяет устранять разногласия и избегать ошибок, вызванных некомпетентностью вашего внутреннего персонала. 9 4 49 Е. Плаксенков: «Нельзя пренебрегать накопленными знаниями. Есть международные стандарты – их и надо использовать. Не стоит зацикливаться на собственной уникальности, потому что в процессе реализации существующего знания рождается новое. А если вместо этого увлекаться процессом, он может ни к чему не привести, кроме тупика». Для начала вы должны определить место МСФО в бизнесе своей организации. Минимальный перечень вопросов, которыми необходимо задаться при организации у себя МСФО: • Кто будет готовить (не аудировать) международную отчетность (МО)? Вы сами или внешние консультанты? Насколько большие вы готовы произвести изменения в текущем учете? • Вы предпочтете параллельный учет или трансформацию? • Нужна индивидуальная отчетность по МСФО либо отчетность необходимо передавать в вышестоящую организацию для консолидации? Ответить на эти вопросы мы постараемся в следующей главе. Всем ли организациям необходимы МСФО? Не только акционерные общества, но и частные российские компании все чаще готовят отчетность о своей деятельности в международном формате. Есть такое выражение: «Плох тот бизнесмен, который не мечтает продать свою компанию». Даже если хозяин не мечтает продать бизнес, он должен адекватно оценивать его стоимость. Очевидно, что оценка стоимости бизнеса производится на основе общепризнанных принципов. Западные или российские инвестиционные фонды рассматривают в качестве таковых МСФО. Так же поступают инвестиционные аналитики, сравнивая компании друг с другом. Не стоит забывать и о принципе сопоставимости показателей за разные периоды времени. Кстати, в погоне за такой сопоставимостью цифр аналитики часто заходят в 5 50 математические тупики. Например, у мобильных операторов есть показатель количества абонентов, появившихся за период. Всеми признано, что с точки зрения бизнеса он не показателен, потому что люди стали покупать по три-четыре sim-карты у разных операторов. Но из-за необходимости преемственности с предыдущими годами данный показатель продолжают отслеживать. И только когда он станет совершенно неактуальным, от него совсем откажутся. Сегодня многие российские компании, особенно успешные в своих отраслях, ориентируются на западных конкурентов и копируют их лучшие практики. При этом сравнимость финансовых показателей достигается только за счет ведения международной отчетности. Практические пути получения международной отчетности Отчетность, сформированная из корпоративной системы управления, в противоположность отчетности, полученной путем «перекладки» уже сформированных фискальных данных, обладает большим кредитом доверия в глазах аналитиков и аудиторов. Потому что с помощью системы легко проверить корректность отчета. Вместо пачки итоговых отчетов аудитору показывают систему: например, демонстрируют электронные архивы документов, предоставляют возможность поиска по штрих-коду отсканированной копии или оригинала любого документа и т. п. С точки зрения структурного описания, МО делят на индивидуальную и консолидированную. Консолидированная всегда представляет собой агрегированные данные индивидуальных отчетов дочерних компаний. В случае с консолидированной отчетностью часто возникают сложные моменты, например необходимость консолидации данных одной и той же дочерней или контролируемой компании в нескольких разрезах. Такие процессы консолидации возможны только с применением систем класса ERP или СРМ. 1 5 51 Рис. 2.4. Пример сложности построения консолидированной отчетности Есть два варианта перекладки индивидуальной отчетности, которые отличаются степенью необходимой точности (рис. 4.5): 1) перекладка суммарных данных за период – трансформация; 2) перекладка каждой транзакции – конверсия. 2 5 52 Рис. 2.5. Консолидация в холдинговых структурах Последний вариант может осуществляться в режиме параллельного ведения двух учетов (параллельный учет) либо путем интерпретации каждого учетного события в двух стандартах сразу (потранзакционно). Параллельный учет – самый неэффективный. Поэтому, говоря о конверсии, мы будем подразумевать автоматическое отражение каждого учетного события в двух стандартах – РСБУ и МСФО. Плюсы и минусы каждого варианта перекладки представлены в табл. 2.2. Таблица 2.2. Конверсия и трансформация Конверсия Организационные требования: - высокие требования к соблюдению учетных регламентов; - высокие требования к организации учета; - методология МСФО должна быть тщательно проработана (на все случаи жизни) Трансформация Организационные требования: - трансформация означает сжатые сроки сбора и обработки информации; - наличие на постоянной основе достаточного количества квалифицированных специалистов МСФО; - эффективное управление большим количеством специалистов, предоставляющих информацию Учетная система должна обеспечивать Особые требования к учетной системе в одновременное ведение в нескольких следующих областях: стандартах учета следующих объектов - контроль корректности данных; учета: - разграничение прав доступа; 3 5 53 - основные средства; - готовая продукция и товары. Необходимо обеспечить разные алгоритмы распределения затрат для разных стандартов учета. Кроме того, естественно, что при конверсии система автоматически рассчитывает курсовые валютные разницы - логирование; - производительность технической платформы, включая аппаратное обеспечение Общие для обоих способов требования к системе: • возможность настройки так называемого мэпинга – соответствия счетов РСБУ счетам МСФО (отображения) и алгоритмов перекладки; • возможность «сверления» данных. Выбор в пользу трансформации целесообразен, когда конверсия физически неосуществима либо экономически нецелесообразна. Альтернативные мнения Тем не менее, многие компании, даже организовав у себя управленческий учет, для генерации международной отчетности используют данные российского бухгалтерского учета. Д. Новоселов: «Отчетность по МСФО мы составляем методом трансформации данных российского бухгалтерского учета в МСФО. Хотя, возможно, когда-нибудь перейдем к параллельному учету. Мы постепенно двигаемся в этом направлении – пока привели российский учет в соответствие и с отечественными стандартам бухгалтерского учета, и со стандартами МСФО. Там, где это возможно. В России создано неплохое законодательство, оно позволяет в широком спектре делать подобные изменения». Примеры перекладки отчетности Кейс № 1 Тип предприятия: производственное. Структура МСФО отчетности: индивидуальная. Вариант перекладки: конверсия (потранзакционно) Инструмент перекладки: Oracle EBS. 4 5 54 Путь перекладки: РСБУ → МСФО. Данные РСБУ достаточно детальные, чтобы на их основе получать управленческую отчетность. Параметры проекта: Срок реализации – три месяца. Значений счетов МСФО в главной учетной книге (ГК) – 4000. Значений счетов РСБУ в ГК – 400. Штат специалистов МСФО: один методолог + один контролер. Частота конверсии – ежемесячно. Кейс № 2 Тип предприятия: розничная сеть. Структура МСФО отчетности: консолидированная. Вариант перекладки: конверсия (потранзакционно). Инструмент перекладки: Oracle EBS. Путь перекладки: Технический учет (регистрация всех учетных событий в EPR-приложении) → Одновременно: РСБУ, УУ и МСФО. Данные технического учета достаточно детальные, чтобы на их основе получать все три вида отчетности. Цифры проекта Срок реализации – три месяца. 800 000 операций и 1200 автоматических корректировок в месяц. Более 250 выделенных бизнес-подразделений. Более 20 юридических лиц. Около 200 финансовых контролеров. Значений счетов МСФО в главной учетной книге (ГК) – 1000. Значений счетов УУ в ГК – 2000. Штат специалистов МСФО: три методолога (не полная занятость). Кейс № 3 Наименование предприятия: ОАО «Связьинвест». Тип предприятия: телекоммуникационный холдинг, контролирующий семь межрегиональных компаний, каждая из которых представляет собой отдельный холдинг, являющийся 5 55 ОАО. В целом организационная структура «Связьинвеста» содержит более 80 региональных предприятий и более 1000 структурных подразделений. Структура МСФО отчетности: консолидированная. Вариант перекладки: трансформация в реальном режиме времени. Инструмент перекладки: Infor МРС. Путь перекладки: РСБУ МРК → МСФО МРК (консолидированные по каждой МРК в отдельности) → МСФО всего холдинга. Параметры проекта Первый релиз системы – четыре месяца. Значений счетов МСФО в главной учетной книге (ГК) – 1000. Значений счетов РСБУ в ГК – 2000. Пользователей: около 900 (находятся во всех часовых поясах и регионах РФ). Штат специалистов МСФО: около 20. Частота трансформации – два раза в год. Выводы Построение УУ по принципам МСФО выглядит логичным по той причине, что последние стандарты: • уже описаны; • понятны профессионалам в области финансов; • могут «подготовить» вас к генерации полноценной МСФОотчетности. Конверсия – самый эффективный способ отображения учетных событий в нескольких стандартах: РСБУ + УУ + МСФО. Однако этот способ очень требователен к методологическому описанию учетных процессов и наличию полнофункционального бизнес-приложения. 6 5 56 Глава 2.4. Роль финансового директора во внедрении и развитии управленческого учета, или «Последние дни» CFO В данной главе речь пойдет о ключевой фигуре вашей организации – финансовом директоре. Последние годы все говорят о том, что в процессеразвития компаний и рынков происходит переосмысление роли финансового директора – Chief Financial Officer (CFO). Но в чем конкретно заключаются изменения? Ведь 80% из 300 опрошенных KPMG CFО1 «средних» компаний по-прежнему лишь контролируют затраты. В России к CFO зачастую по-прежнему относятся как к корпоративному кассиру, который должен вовремя и оперативно сформировать платежный календарь, взять кредит и т. д. Не хватает перспективного, стратегического видения их роли. Соответственно, не формируется и их отношение к самим себе как к стратегическим игрокам. Но есть и хорошая новость: финансовые директора преуспевающих компаний (международных и российских) все яснее понимают, куда двигаться, как меняться, какую роль играть, а главное – какие на этом пути есть проблемы. Многие финансовые директора становятся публичными персонами, объясняющими с финансовой точки зрения стратегию компании вне зависимости от того, частная она или публичная. CFO все активнее участвуют в формировании IT-пространства своей организации. Сегодня одна из важнейших проблем CFO – кадры. Финансовые директора часто не могут подобрать в свои департаменты необходимый персонал. Если раньше ключевым требованием к финансовому специалисту было наличие экономического образования, то сейчас от него требуются такие 7 5 57 навыки, как лидерство, управление изменениями, ИТквалификация. И все это должно сочетаться в одном человеке. Интерактивный on-line-обзор CFO Research Services необычайно интересен. В нем приняло участие более 1600 специалистов финансового сектора, причем более половины – сотрудники компаний с оборотом от полумиллиарда долларов. Главный вопрос – личный: «Считаете ли вы себя активистом?» Сам факт того, что этот вопрос задается, показывает, как изменилось отношение к финансистам. От них ждут уже не просто правильных цифр в нужное время, но активной позиции. Финансисты, читающие эти строки: считаете ли вы себя не просто «оптимистами», а «активистами»? 40% участников опроса ответили, что они – активисты. Остальные, видимо, вырвались из рутины только для того, чтобы поучаствовать в опросе. Большинство активистов сотрудничают с советом директоров и учредителями своей компании более двух лет. То есть основной критерий активности финансового директора – взаимодействие; постоянное и «проактивное» взаимодействие с акционерами. Следующий интересный вопрос опроса: «Выберите, какое определение вам больше всего подходит». Половина активистов выбрала для себя как наиболее подходящую характеристику определение «навигатор роста». Как правило, это представители компаний, которые быстро развиваются за счет стремительного роста рынка либо за счет приобретения других фирм. В основном это касается компаний банковского сектора, фармацевтики, HiTech и профессиональных сервисов. 28% ответивших считают себя «маэстро исполнительности». Они видят свою задачу в том, чтобы научить всю организацию делать то же самое, что всегда, но более эффективно, быстро и просто. Такое происходит в энергетике, страховании, на транспорте, в ритейле и сфере обслуживания отелей и ресторанов. 12% считают себя «офицерами реформ». Это люди, которые берут на себя ответственность за принятие сложных, непопулярных решений и их воплощение в жизнь. Как правило, 8 5 58 это представители компаний, нуждающихся в серьезной реструктуризации. Судя по ответам респондентов, подобные изменения сейчас происходят по всему миру в автопроме, электронике, пищепроме и телекоме. CFO жалуются: взаимодействие с советом директоров – сплошной стресс. Но та же статистика из того же опроса говорит о том, что, если вы все-таки выдержали натиск и общаетесь с советом директоров около двух лет, психологический дискомфорт сходит на нет, общение переходит в русло нормальной работы. И финансовые директора становятся генеральными... В статье, озаглавленной «Организоваться, чтобы создавать ценность», Дэвид Нортон утверждает: «Слово «ценность» стало синонимом выражения «нематериальные активы», что заключает в себе намного больше, чем просто финансовый менеджмент». Далее он задает вопрос: кто должен осуществлять процесс создания ценности внутри организации? И предполагает, что хотя финансовые директора обладают умением осуществлять эту функцию, только немногие занимаются этим на самом деле. Нортон говорит, что на исполнительном уровне может появиться новая должность для решения данной проблемы – директор по ценности (Chief Value Officer, CVO). Независимо от того, кто займет эту позицию, сегодняшние профессионалы бизнеса, как первые исследователи космоса, живут в век, который одновременно ужасно интересен и опасен. Руководители высшего звена (и организации), которые развивают и демонстрируют стратегическое (как в финансах, так и в других сферах) мышление, понимают, как обращаться с технологией, чтобы повлиять на стратегию организации, добавить ценность и показать акционерам возможность преодолеть брешь между стратегией и ее исполнением. Вот простой документ – оперативный план платежей или ДДС. Почему оперативный – есть разные периоды бюджетирования: стратегический период и стратегический бизнес-план, бюджетный период – это год, оперативный период – месяц. Исполнением и отслеживанием оперативного плана 9 5 59 занимается финансовый директор завода, а не операционный менеджер. Финансовый директор предприятия должен в первую очередь заниматься стратегическим бизнес-планом и в равной степени — бюджетом. За что отвечает финансовый директор в этом отчете? Он не отвечает за итоги операционный деятельности. Это – сфера ответственности всего менеджмента компании. Он отвечает за два раздела – инвестиционную и финансовую части. За финансовую часть понятно, почему – управляет финансовыми потоками, финансовой стратегией. В инвестиционной части он является таким же важным лицом, как и в стратеги компании; экспертом по оценке инвестиционных проектов и инвестиционных же стратегий. Причем не отдельного проекта, а комплекта (портфеля) проектов. Таким образом, финансовый директор отстраняется от решения частных задач. Если он сегодня не решится на внедрение системы или чего-то еще, так и будет распыляться по мелочам. А проблемы гораздо глубже. Не имея стратегии привлечения денег на какой-то период, через два года невозможно будет исполнить инвестиционный бюджет. А без стратегии выплаты дивидендов нельзя привлечь инвесторов. Отсутствие стратегии в области налоговой политики через некоторое время может привести к тому, что компания будет неэффективно платить налоги. Или наоборот. На примере растущей компании нарисуем общую картину. Фирма начинает агрессивно расти. Что это значит? Сначала возникает огромная потребность в рабочей силе, затем – в инвестициях. У компании – плохой денежный поток. Растущая организация должна вкладываться в дебиторку – это потребность в рабочем капитале, инвестициях и новых объектах, генерирующих новые денежные потоки. А если финансовый директор заранее не решит, как будут амортизироваться активы? Ведь чтобы платить меньше налогов, надо сделать большую амортизацию. При этом инвесторы смотрят на один показатель – отношение долга к EBITDA. EBITDA будет максимальная, прибыль – достаточно маленькой (мы платим проценты за кредиты и амортизируем), налоги тоже. Денежный поток 6 60 улучшается, a EBITDA растет, и мы можем привлечь много денег. Такое простое решение позволит компании развиваться, больше инвестировать. И это все на фоне увеличивающейся конкуренции между финансовыми директорами. Есть две компании: одна – владелец актива, вторая пытается к ней присоединиться. Обе будут стремиться создать совместный инвестиционный проект. В то же время происходит битва умов на финансовом уровне. Потому что каждая компания хочет получить лучшие условия и самую выгодную часть проекта, максимальный денежный поток и окупаемость. Если актив – прибыльный и его хватит на всех – одно дело, а если куш невелик, участники вступят в жесткое противоборство. Могут и не договориться. Но не факт, что это будет плохо. Кроме переговоров бизнес-менеджеров, здесь еще важно и качество работы финансового менеджера: как он просчитал инвестиционную политику и как повлияет вхождение в инвестиционный проект на состояние организации. Впишется ли проект в ту систему, о которой я говорил раньше, – по максимизации EBITDA при одновременном снижении налогового бремени. Нюансов – масса. То же касается сделок типа «слияние» и «поглощение». Кто знает их цену? Никто! Цена – результат битвы между финансистами. Потому что бизнес-аналитики могут говорить что угодно, для них все всегда – допущение. А финансисты выторговывают условия и показывают, какой вариант при каком раскладе получится. Один старается нарисовать компанию лучше, чем она есть, второй – понять, где он все это видит. Сегодня финансовый директор становится стратегом, частью бизнеса; пусть даже не той, которая формирует стоимость компании. Бухгалтер формирует реальность. Значит, финансовый директор, который нанял этого бухгалтера, влияет на формирование реальности: взял на работу хороших людей – получилась хорошая реальность, если спецы так себе – реальность соответствующая. Опять же про игры разума – любая финансовая отчетность тоже превращается в игру. Все зависит от того, как мы это проведем. Один и тот же актив можно 1 6 61 оформить по-разному: часть отнести на текущие расходы, половину – на капитализацию. Финансовые результаты будут разные, и результат у компании – тоже. И все виды отчетности, включая МСФО, направлены лишь на то, чтобы как можно прозрачнее представить замысел бухгалтера. Убедить всех внутренних пользователей – тоже проблема. Основная проблема финансов – общечеловеческая. У каждого есть кошелек с деньгами. Если я умею их тратить, наверное, я что-то смыслю в финансах. Это общечеловеческий подход. И если о маркетинговых решениях никто не спорит, то о финансовых решениях может спорить каждый, до бесконечности. Так каждый член бюджетного комитета знает, сколько стоит чашка кофе, и никто – цену ядерного реактора. Про реактор никто не спорит, а про то, что кофе сотрудникам в офис за 20 долларов – дорого, все кому не лень. Глава 2.5. Что бы мы сделали по-другому О. Рябов: «Когда мы делали хранилище данных, серьезно недооценили требования по его состыковке с существующими системами — не ожидали, что купим столько компаний. Мы также ошиблись в формировании требований по организации интерфейса между внедряемыми системами, так как заранее не спрогнозировали, сколько времени займет сведение воедино всех систем. Из-за этого даже пришлось перезапускать проект (стоило денег и времени). Еще один урок! При автоматизации оперативного учета надо было больше времени потратить на «тренировку» — попробовать силы на маленьком регионе, а не разворачиваться сразу на Москву, что сильно дезорганизовало работу. Мы хорошо укрепили сектор финансов и операций, но обработка поставок вызвала сложности. Недостаточно обученные люди не могли взять на себя ответственность. Касательно выбора бизнес-приложений не могу сказать, что мы ошиблись. Каждый раз предпочтение отдавалось в пользу лучшего решения». 2 6 62 Е. Плаксенков: «Любая постановка управленческого регулирования в процессе реализации приводит к новому пожеланию. Рождаются вариации: «можно так, а можно подругому», «а правильно ли мы идем?», «а давайте сделаем не так». И в этот момент всегда есть вероятность поддаться соблазну «доделок». Например, вы создаете самолет, и в какой-то момент, когда он уже почти готов, вам говорят: "Давайте сделаем так, чтобы в самолете можно было не только летать, но и плавать". Вы отвечаете: «Точно, давайте приделаем к самолету парус...» И добавляют: «А еще, чтобы самолет мог копать, давайте лопату приделаем». Эти желания и «давайте еще» – самые опасные, потому что у человека, по-настоящему включившегося в процесс и увлеченно над чем-то работающего, автоматически рождаются новые идеи. Надо уметь реализовать задуманное ранее, при этом не забыть идеи и не нарушать идеями стройную картину, которую решили воплотить в жизнь. Наметил проект – реализуй. А сгенерированные по ходу новые идеи необходимо сохранить, чтобы с их помощью обогатить полученный результат. Я твердо уверен: любой проект, особенно финансовая постановка управленческого учета, должен стремиться к максимальному сокращению сроков реализации. Чем он длиннее, тем больше изменений возникнет. А они, в свою очередь, могут привести к корректировке проекта и срыву сроков. Тем компаниям, которые лишь приступают к постановке управленческого учета, я бы порекомендовал следующее. Руководителю нужны три вещи: 1. Понимание бизнеса как системы. 2. Понимание его роли в отрасли, экономике и на рынке. Если ты понимаешь свой бизнес как систему, ты осознаешь его роль, понимаешь структуру, цели и т. д. 3. Не пренебрегать накопленными знаниями, а смело их реализовывать. Есть международные стандарты – бери и используй. Есть написанная книга – читай. Не надо бояться использовать то, что уже сделано, и сделано хорошо. Не надо 3 6 63 упираться в собственную уникальность, потому что в процессе реализации существующего знания рождается новое. А если зацикливаться на процессе, можно зайти в тупик». Д. Новоселов: «Что бы мы сделали сейчас по-другому? Четыре года назад внедрили бы SAP или аналогичную ERP с помощью консультантов. Существует мнение, будто от системы мало что зависит и если все нормализовать, можно обойтись и без нее. Но это не так. У нас проблема не с самой «Галактикой», а с тем, как мы ее внедрили и настроили. Было допущено много ошибок – в бизнес-процессах и их описании, во время внедрения и настройки. А когда в системе уже ведется учет, исправить сложно. Некоторые проблемы, чтобы исправить, еще надо найти. Программисты, с которыми мы работали, зачастую не понимали, зачем они все это делают, а экономисты не понимали, как оно работает и что внутри. Консультанты необходимы для связки – они должны понимать, какие конечные требования по бизнес-процессам существуют у пользователя и как настроить систему, чтобы одно требование не противоречило другому. При качественном внедрении системы с их участием данное правило обычно выполняется. В качестве дополнительных преимуществ внедрения полноценной ERP-системы я вижу реализацию целого ряда механизмов внутреннего контроля. Простой пример, реализуемый даже в «1С»: существует контрагент, цена единицы товара указана в накладной. Маленькая проверка, которая под силу учетной системе, – сравнить текущую цену накладной с ценой, которая занесена или статистически сложилась в справочнике цен. В чем заключается проблема введения накладных? Оператор может вместо рублей ввести доллары либо евро, напутать с единицами измерений. При этом он может полениться все еще раз проверить или просто не заметить – цифры правильные, а в систему ушла накладная с ошибкой. Эти ошибки рано или поздно будут обнаружены, но придется потратить дополнительные ресурсы на проверку, что 4 6 64 снижает доверие к системе и скорость работы в целом. Правильнее и в конечном итоге эффективнее организовать простые проверки на входе в систему и элементарно отслеживать такие огрехи. Вот несколько алгоритмов, которые позволяют не совершить подобных ошибок: при вводе валюты и при проведении платежа в учетной системе сверяться со справочником цен. Если цена отличается больше, чем на 20% (10%), выскакивает предупреждение: «Цена отличается на столько-то. Вы уверены?». Если пользователь выбирает: «Да, уверен», все хорошо. Если нет, он начинает проверять и обнаруживает, что ввел не ту валюту либо не ту ставку НДС, еще что-то упустил. Такие инструменты можно придумать на любом участке учета и быть уверенным – все первичные документы введены правильно. Подобные элементы контроля стоит предусмотреть в момент внедрения системы. Уже имеющуюся ситуацию можно изменить коренным образом, только внедрив новую ERP-систему или перевнедрив существующую (сопоставимо по ценам). К сожалению, внедрение полноценной ERP, например SAP, для нас сегодня дорого и, наверное, на данном этапе жизни компании не оправданно». Всегда очень важно не слишком поздно и не слишком рано что-либо внедрять. Конец четвертой лекции Все замечания и предложения отсылайте по адресу: feedback@rfei.ru. 5 6 65