Глава 8 Моделирование бизнес-процессов

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

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

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

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

• информационные связи между объектами и с внешней средой;

• передаваемые в соответствии с информационными связями документы, данные, информацию;

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

• классификацию и кодирование в системе.

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

• независимость идентификации показателей от их расположения в документе;

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

• применимость к любым объектам, встречающимся в данной предметной области;

• полноту классификации (по всем существенным свойствам);

• наличие соглашений, упрощающих кодирование;

• использование международных стандартов;

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

Функциональная полнота системы базируется на классификации,

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

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

3.1.1. Методологии моделирования структуры организации

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

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

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

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

• при необходимости отражения идеально отлаженного механизма деятельности;

• при начальных попытках формирования модели, когда все понятное еще далеко впереди.

Чаще встречается значительно более сложная ситуация, занимающая промежуточную позицию между этими крайностями: все вроде бы понятно, но при попытках формализовать взаимоотношения возникает "сплошной туман". В этом случае действенную помощь может оказать хорошо разработанное семейство методологий IDEF, являющееся государственным стандартом в США. Оно состоит из методологии функционального моделирования IDEF0 и методологии IDEFl(X). Предполагалось создание стандарта на методологию динамического моделирования IDEF2, однако стандарт так и не был создан (тем не менее существуют системы динамического моделирования, преобразующие статические модели семейства IDEF0 в модели на базе "раскрашенных сетей Петри").

IDEF-методологии создавались в рамках предложенной ВВС США программы компьютеризации промышленности - ІСАМ, в ходе реализации которой выявилась потребность в разработке методов анализа процессов взаимодействия в производственных (промышленных) системах. Принципиальным требованием при разработке рассматриваемого семейства методологий была возможность эффективного обмена информацией между специалистами-участниками программы ІСАМ, что определило название самой методологии Ісат DEFinition, т.е. IDEF. После опубликования стандарта он был успешно применен в самых различных областях бизнеса, показав себя эффективным средством анализа, конструирования и отображения бизнес-процессов. Более того, с широким применением как IDEF, так и предшествующей методологии - SADT - связано возникновение основных идей понятия BPR (Business Process Reengineering).

К особенностям этого семейства методологий можно отнести:

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

• неразрывную связь графических средств (нотации), методологии и технологии.

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

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

Поскольку, как правило, моделирование проводится в тех случаях, когда требуется не просто описать объект, а выявить его новое содержание (например, для целей создания корпоративной информационно-аналитической системы либо в ходе реинжиниринга бизнес-процессов), то все потоки в системе должны быть выявлены и описаны достаточно детально. Отсюда вытекает целевая задача методологии IDEFl(X): определить, какая информация требуется для реализации функций, описанных диаграммой IDEF0. Методология IDEFl(X) является разновидностью методологии ER-диаграмм (Entity-Relationship, т.е. модель "сущность - связь"). Она строго формализована и адаптирована для совместного использования с IDEF0 как "дуальная" (двойственная) к ней в рамках единой технологии моделирования. Двойственность методологии проявляется в том, что в рамках IDEF0 детализируются функциональные блоки, а в IDEFl(X) подлежат детализации потоки, взаимодействующие с функциями.

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

3.1.2. Процессный подход к моделированию управления

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

Успешное внедрение процессного подхода во многом зависит от использования профессиональных инструментальных средств, позволяющих описывать и проводить анализ бизнес-процессов, делать их более прозрачными и управляемыми. Одним из примеров подобных программных сред является семейство продуктов ARIS (Architecture of Integrated Information Systems), разработанных компанией IDS Scheer AG и предназначенных для структурированного описания, анализа и последующего совершенствования бизнес-процессов предприятия, а также для подготовки к внедрению сложных информационных систем.

Методология ARIS рассматривает структуру предприятия в четырех аспектах:

• организационная структура предприятия;

• структура функций объектов управления;

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

• структура протекающих процессов.

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

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

• ЕРС (Event-driven Process Chain) - метод описания процессов по событиям, нашедший применение, в частности, для описания процессов системы SAP R/3;

• ERM (Entity Relationship Model) - модель "сущность - связь" для описания структуры данных;

• UML (Unified Modeling Language) - объектно-ориентированный язык моделирования.

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

Семейство продуктов ARIS состоит из двух основных продуктов (ARIS Easy Design и ARIS Toolset) и ряда функциональных модулей.

Комплекс AR1S представляет собой единую среду моделирования, объединяющую четыре основных компонента: Explorer (проводник), Designer (средство для графического описания моделей), Tables (таблицы для ввода различных параметров и атрибутов) и Wizards (мастера). Различие двух продуктов заключается не в методологической части (ARIS Easy Design входит в AR1S Toolset), а лишь в функционале. Продукт ARIS Easy Design ориентирован на сбор информации и документирование, a ARIS Toolset - на комплексный анализ и семантические проверки информации.

Преимуществом AR1S перед другими средствами описания бизнес-процессов является отсутствие необходимости взаимодействия функциональных модулей (АВС-анализ, динамическое моделирование, настройка и генерация отчетов) через какие-либо программные интерфейсы. ABC-анализ (Activity-Based Costing - пооперационное исчисление стоимости) позволяет рассчитать стоимость выполнения отдельных операций при реализации бизнес-процессов и тем самым определить потребности для всей совокупности процессов. Все данные, используемые основными продуктами и дополнительными функциональными модулями, хранятся в едином репозитории и не требуют проведения операций по экспорту или импорту используемых данных.

Таким образом, методология AR1S едина для любого функционального модуля и может быть ограничена (с помощью ARIS Toolset) с учетом целей проекта и потребностей пользователей. В настоящее время имеются интерфейсы для ARIS к CASE-средствам, системам WorkFlow, системам GroupWare, разработанные сторонними компаниями. Эти интерфейсы представляют собой приложения, которые через промежуточный файл трансформируют данные формата ARIS в данные формата конечного средства.

3.2. Организация процесса внедрения систем

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

это не просто автоматизация подразделений организации. Это принятие стратегического решения.

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

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

• особенности развертывания и конфигурирования;

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

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

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

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

При выборе системы помимо указанных бизнес-требований целесообразно принимать во внимание также следующие факторы:

• возможность интеграции с программными (в основном системными) продуктами, обеспечивающими работу организации;

• возможность снижения затрат на клиентские лицензии;

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

• возможность поддержки протоколов РКІ и Х.509, необходимых для полной поддержки электронной цифровой подписи;

• соответствие нормам отечественного делопроизводства;

• требования к защищенности данных;

• возможность настройки на существующую и перспективную организационную структуру предприятия;

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

• возможность интеграции с внешними приложениями.

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

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

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

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

• уточняются процессы документационного обеспечения управления и маршруты движения документов;

• формируются и утверждаются корпоративные каталоги, справочники и классификаторы;

• определяются подразделения и должностные лица, поэтапно вовлекаемые в электронный документооборот.

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

Создание и документальное оформление _команды выполнения проекта_

Обеспечение возможности миграции на любую систему

Уточнение процессов и маршрутов движения документов

Формирование и утверждение корпоративных каталогов, справочников и классификаторов

Определение подразделений и должностных лиц, вовлекаемых в документооборот на каждом этапе

-,

Разработка регламентов проведения работ

Документальное оформление открытия работ, формирование и согласование всех необходимых документов

Рис. 3.3. Планирование работ при внедрении системы

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

3.3. Обследование объекта и органов управления

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

3.3.1. Общая характеристика процесса обследования

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

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

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

• получения полной и систематизированной исходной информации о процессах функционирования объектов и систем управления;

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

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

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

Первое направление включает непосредственный сбор и представление исходной информации о следующих вопросах:

• о существующей системе и объектах управления;

• о порядке (алгоритмах) и способах решения задач;

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

• о составе информации, необходимой для решения задач в процессе управления информационным обменом.

Второе направление охватывает следующие работы:

• анализ полученной информации;

• оценку ее достоверности, полноты и связанности;

• формализованное описание процессов управления в целях создания многоуровневой информационной модели процессов управления.

Основная цель обследования предприятия - формирование информационной модели, объединяющей процессы, протекающие в системе.

Объектом исследования при разработке и последующем использовании информационной модели является процесс управления структурными подразделениями и бизнес-процессами.

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

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

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

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

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

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

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

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

Информационная модель обследования предприятия включает следующие компоненты (рис. 3.4):

• оперативный алгоритм управления;

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

• функциональный алгоритм управления;

• алгоритм преобразования информации;

• комплект форм документов;

• состав информации обмена;

• словарь терминов.

При формировании информационной модели учитываются:

• условия управления (регулярные, нештатные);

• уровень (звено) управления;

• состав должностных лиц и формы их деятельности;

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

• цели и задачи, решаемые на каждом уровне управления;

• функции управления;

• особенности подготовки и принятия управленческих решений.

Словарь терминов

Состав информации обмена

Т, J * экономическая оценка вариантов ее построения.

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

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

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

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

• совокупность мероприятий, характеризующих выполнение данной задачи;

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

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

• применяемые технические средства;

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

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

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

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

• объемы и состав информации, выдаваемой и получаемой должностными лицами в процессе выполнения ими своих функций;

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

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

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

информации, которая охватывает:

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

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

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

• формы отображения используемой информации;

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

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

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

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

3.3.3. Документирование информации при обследовании

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

1. Использование унифицированных форм представления результатов обследования. Подобный подход позволяет:

• упростить согласование и процедуру передачи результатов работы одних специалистов другим;

• обеспечить взаимозаменяемость специалистов в процессе работы по обследованию предприятия;

• формировать однотипное представление информации и ввод корректировок;

• сократить время на контроль качества выполнения каждого этапа обследования.

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

• с меньшими временными затратами выяснить специфику процессов, происходящих в системе;

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

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

• выявить однородные структуры на разных объектах и при решении различных функциональных задач;

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

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

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

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

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

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

Более наглядным является метод представления информации при обследовании процесса решения управленческой задачи в таблично-матричной форме (рис. 3.7).

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

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

Формирование предложений по развитию производства

Задача

управления

Мероприятия Исполнители

Отдел 1 Отдел 2 Отдел 3 Бухгалтерия

Время

выполнения Частота

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

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

Документационная характеристика функциональных групп Задача Основание

для

выполнения Инициатор

решения Частота

выполнения

і

і_ _____ . Продолжи

тельность

выполнения Итоговый

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

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

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

3.4. Практические аспекты внедрения

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

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

3.4.1. Подход к функциональному тиражированию

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

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

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

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

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

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

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

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

3.4.2. Учет российской специфики при внедрении западных систем

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

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

Многие западные системы (например, SAP R/3 или BAAN) позволяют поддерживать специальную Главную книгу с автоматическим переносом в нее бухгалтерских документов и последующим получением отчетности по альтернативному набору отчетных периодов, но использование данной функциональности достаточно трудоемко как в плане конфигурации, так и в аспекте дальнейшей поддержки системы.

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

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

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

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

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

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

Так, например, в системе SAP R/3 предусмотрена возможность использования альтернативной нумерации счетов. Данные номера счетов не могут быть использованы при проводке документов, однако ряд отчетов позволяет выводить требуемые данные с заменой основной нумерации на альтернативную. Учитывая вышесказанное, рекомендуемым решением является создание в системе собственного плана счетов в соответствии с российскими стандартами и ведение альтернативных счетов для поддержки их соответствия с корпоративным планом счетов.

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

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

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

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

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

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

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

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

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

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

Например, в системе SAP R/3 имеется стандартная функциональность для ведения авансовых платежей, и она известна всем российским специалистам в области внедрения системы, а следовательно, и не заслуживает подробного изложения. Гораздо менее распространенный вариант - предварительная регистрация счета (еще отсутствующего) и ввод в систему запроса на оплату вместо запроса на предоплату с последующей автоматической генерацией платежа. Такой вариант позволяет избежать дополнительной конфигурации системы, однако имеет два существенных недостатка. Первый из них - отсутствие отдельного счета, на котором отражается задолженность по предоплатам, а второй - отсутствие достаточно точных данных на этапе предварительной регистрации счета. Конечно, система позволяет автоматически перенести остаток по авансовым платежам на отдельный счет в конце месяца и откорректировать счет при его проводке, однако пользователи будут испытывать определенные неудобства.

Платежи в рублях с пересчетом некой суммы в твердой валюте по курсу на день оплаты получили в России широкое распространение. Осуществлять пересчет сумм к оплате вручную возможно, но трудоемко, к тому же при этом невозможно заранее подготовить пакет документов, подлежащих оплате. Достаточно распространенным решением является создание дополнительных кодов валют для каждого типа условных единиц (например, оплата суммы в евро, пересчитанных в рубли по курсу Банка России, плюс 1 %) и ежедневное ведение соответствующим образом рассчитанных курсов для каждой из них. В этом случае система сгенерирует платеж на основе предварительно введенного запроса в выбранной технической валюте, рассчитав приведенную сумму во внутренней валюте, т.е. рублях. Данная сумма и должна быть взята для печати платежного поручения вместо суммы в валюте транзакции. Однако возникает необходимость связать данный документ со счетом-фактурой, проводимым в рублях, что может генерировать вопрос о корректности формируемой отчетности по НДС. Потенциально данная проблема решается легко, если проведена доработка программы платежей, позволяющая проводить платеж в валюте, отличной от валюты запроса на платеж.

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

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

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

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

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

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

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

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

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

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

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

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

Вопросы для самоконтроля

1. Что характеризует информационная модель бизнеса?

2. Какие аспекты учитываются при формировании системы взаимодействия структурных компонентов предприятия (организации)?

3. Какие возможности обеспечивает применение процессного подхода к моделированию управления?

4. Какие этапы проходит процесс внедрения системы управления?

5. Какие факторы учитываются при выборе системы управления?

6. Каковы задачи проведения обследования?

7. Что является результатом проведения обследования?

8. Что представляют собой оперативный, функциональный и информационный алгоритмы управления?

9. Как можно представить информационную модель обследования?

10. Какая информация должна быть получена в результате проведения обследования?

11. Какова структура методики проведения обследования?

12. Какие требования предъявляются к информации, получаемой в процессе обследования?