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

Фактически любая КИАС содержит в своем составе систему ФЭУ, с другой стороны, современные "интегрированные" ФЭУ поддерживают значительный набор опций, типа документооборота, электронной почты, связи с Интернет и тому подобных, "типичных" для КИАС, ввиду этого мы будем использовать далее КИАС и "система ФЭУ" практически, как синонимы. При этом в отечественной практике при создании системы управления приходится создавать и технологию, что и было вынесено в заголовок данного материала.

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

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

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

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

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

• методология планирования бизнес-ресурсов
• система управления затратами и себестоимостью (контроллинг)
• MIS (Managment Information System) -- система поддержки принятия решений

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

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

Методология ERP содержит следующие элементы:

• планирование потребности в материалах (MRP)
• планирование потребности в мощностях (CRP)
• планирование потребности в финансовых ресурсах (FRP).

Как видно из приведенного выше списка, данная методология является дальнейшим развитием известных методологий MRP (material requirements planning) и MRP II (material resource planning). В мировой практике важнейшей причиной создания данной методологии было резкое сокращение длительности "жизненного цикла изделия", то есть времени от момента представления товара (изделия) на рынок, до резкого снижения уровня прибыли от его продаж, что требует замены товара на новый, или привлечения средств для увеличения объема продаж за счет маркетинговых акций. В Российской практике, дополнительно к вышесказанному, важнейшее значение имеет необходимость антиинфляционного и "антиналогового" управления фирмой, а во многих случаях и "антикризисного". Последнее приводит к тому, что, в отличие от Запада, где мощность системы почти прямо связана с размерами предприятия, системы класса ERP в России требуются даже многим небольшим, но активно работающим компаниям.

Методология управления затратами и себестоимостью

• учет и анализ затрат;
• управление себестоимостью и ценой продажи;
• анализ cash flow (финансовых потоков).

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

Managment Information System (система поддержки принятия решений)

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

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

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

В связи с этим можно выделить как минимум три, практически наиболее часто встречающихся, подхода к формированию КИАС (ФЭУ):

• случайный, то есть при наличии средств интуиция или случай подсказывает купить какую-нибудь систему "потяжелее"
• от частных запросов. Такой вариант возникает как правило в активно работающих коммерческих структурах (в том числе и банках), имеющих относительно молодых менеджеров и/или продвинутую бухгалтерию. Еще часто такой вариант возникает на промышленных производственных предприятиях, на которых и ранее большое внимание уделялось расчетам себестоимости и контролю затрат
• от общей постановки. Такой вариант относительно редок и возникает только в весьма продвинутых в технологическом отношении коммерческих структурах.

По другому рассмотренную выше схему можно изобразить следующим образом:

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

К сожалению, практика внедрения, систем ФЭУ в России позволяет однозначно сделать вывод о необходимости следовать "правильному" пути, то есть даже если и первичная постановка возникла от "частных" задач, то необходимо сначала произвести постановку полномасштабного управленческого учета, а только затем переходить к построению КИАС.

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

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

Еще раз повторим наши "факторы успеха", несколько детализировав их содержание.

Постановка задачи

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

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

Обучение специалистов

• GAAP;
• ERP (методология планирования бизнес-ресурсов);
• поддержка "тяжелых" систем.

Поясним.

Общепринятое обучение ГААПу, как правило, не дает представления о нем, как о "системе" бухгалтерского учета, ориентированной на управление финансами.

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

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

Технология моделирования

• Reference model (IDEF0)
• Модель процессов (IDEF3)
• Модель информационных структур (IDEF1X)

Прокомментируем последнее требование. Для эффективного управления проектом создания (внедрения) КИАС требуется детализованное описание и документирование всех его этапов. Особенно важным представляется наличие описания проекта, независимое от конкретной технологии реализации, так как возможны ее изменения, использование нескольких технологий одновременно и т.д. и т.п.. Таким описанием и является "reference model" в нашей терминологии.

Технология моделирования, применяемая для ее построения, должна, по нашему мнению, удовлетворять следующим требованиям:

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

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

Ниже коротко перечислим основные свойства и задачи методологий семейства IDEF.

IDEF0

• методология функционального моделирования
• создание "reference model"-основы для дальнейшей работы
• бизнес-процесс реинжиниринг -- модификация деловых процедур

IDEF1X

• методология информационного моделирования
• описание структур данных
• проектирование баз данных

IDEF3
Пример технологической карты

• методология моделирования процессов
• проектирование процедур
• описание технологических карт

IDEF5

Пример модели

• методология "онтологического" проектирование
• "концептуальное" проектирование
• "предварительный" анализ

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

• длительность (задача ставится "в последний момент")
• отсутствие квалифицированных специалистов (особенно менеджеров и системных аналитиков)
• отсутствие интегрированных средств поддержки полного жизненного цикла системы

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

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

Но предположим, вы все таки решились на проект создания КИАС.

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

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

Данная модель позволяет достаточно четко разнести программно прикладные системы обладающие хотя и формально ( при общем перечислении) похожими, но функционально существенно отличающимися возможностями (кстати, по-видимому, только в России, такие системы как, например, Scala и R/3 или SunSystem и BAAN, могут выступать как конкуренты в одном тендере).

Итак, принципы классификации:

• Количество функциональных подсистем
• Качество (уровень) взаимосвязи между подсистемами
• Опция конкретного клиента (например -- аппаратная платформа)

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

• "куб предложения"
• "точка выбора"
• "куб возможностей", что графически представляется следующим образом:

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

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

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

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

© Сергей Колесников; 1998, 1999