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

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

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

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

Функциональная методика IDEF0

Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT ( Structured Analysis and Design Technique ). Исторически IDEF0 как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing ). Семейство стандартов IDEF унаследовало свое обозначение от названия этой программы ( IDEF = Icam DEFinition), и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США ( NIST ).

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

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

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

верхняя сторона имеет значение "Управление" (Control);
левая сторона имеет значение "Вход" (Input);
правая сторона имеет значение "Выход" (Output);
нижняя сторона имеет значение "Механизм" ( Mechanism ).

Рис. 6.1.

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

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

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

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD ( Data Flow Diagram ) и WFD (Work Flow Diagram).

Декомпозиция ( Decomposition ) является основным понятием стандарта IDEF0 . Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции . При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

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

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

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

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

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

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

Иногда отдельные интерфейсные дуги высшего уровня не имеет смысла продолжать рассматривать на диаграммах нижнего уровня, или наоборот - отдельные дуги нижнего отражать на диаграммах более высоких уровней – это будет только перегружать диаграммы и делать их сложными для восприятия. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования . Обозначение " туннеля " (Arrow Tunnel ) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из " туннеля ") только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока–приемника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии, – в таком случае они сначала "погружаются в туннель ", а затем при необходимости "возвращаются из туннеля ".

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

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

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

Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов, создавая модели деятельности подразделений. При этом их интересуют ответы на следующие вопросы:
Что поступает в подразделение "на входе"?
- Какие функции и в какой последовательности выполняются в рамках подразделения?
- Кто является ответственным за выполнение каждой из функций ?
- Чем руководствуется исполнитель при выполнении каждой из функций ?
- Что является результатом работы подразделения (на выходе)?
На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели.
Распространение черновика для рассмотрения, согласований и комментариев. На этой стадии происходит обсуждение черновика модели с широким кругом компетентных лиц (в терминах IDEF0 - читателей) на предприятии. При этом каждая из диаграмм черновой модели письменно критикуется и комментируется, а затем передается автору. Автор, в свою очередь, также письменно соглашается с критикой или отвергает ее с изложением логики принятия решения и вновь возвращает откорректированный черновик для дальнейшего рассмотрения. Этот цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению.
Официальное утверждение модели. Утверждение согласованной модели происходит руководителем рабочей группы в том случае, если у авторов модели и читателей отсутствуют разногласия по поводу ее адекватности. Окончательная модель представляет собой согласованное представление о предприятии (системе) с заданной точки зрения и для заданной цели.

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

Подходом, основанным на методологии общего описания и функционального моделирования бизнес- процессов, является методология IDEF0. В основе ее лежит методология интегрированного компьютеризированного производства (Integrated Computer-Aided Manufacturing - ICAM), использовавшаяся в военно-воздушных аэрокосмических лабораториях США в процессе разработки и создания новых видов самолетов и космических аппаратов. Позднее на этой основе был разработан и введен в действие в 1993 г. федеральный стандарт США по информационным технологиям - Публикация? 183 (Federal Information Processing Standard, Publication 183).

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

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

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

Рисунок 1. Иерархия детализируемых диаграмм в IDEF0.

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

Стрелки могут быть четырех видов:

Рисунок 2. Позиционирование стрелок в модели IDEF0.

Входы ( Input ) и Выходы ( Output ) (подходят слева к блокам и выходят справа от них) — представляют собой данные, объекты, материалы и т.п., относящиеся к выполняемым блоками функциям (это, как правило, перерабатываемые ресурсы и результаты выполнения отдельных функций блоков);
Механизмы выполнения функций ( Mechanism ) (подходят снизу к блокам) — представляют собой долговременные ресурсы, необходимые для выполнения соответствующих работ (это могут быть конкретные работники, подразделения организации, машины, оборудование, компьютерная техника и т.п.);
Управление или регламентирующие документы ( Control ) (подходят сверху к блокам) − представляют собой условия, директивы, руководящие документы и т. п., управляющие выполнением данной функции.

Компоненты синтаксиса IDEF0 - блоки, стрелки, диаграммы и правила.

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

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

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

Рисунок 3. Стрелки на IDEF0-диаграмме.

Для блоков установлены следующие синтаксические правила :

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

Для стрелок установлены следующие синтаксические правила :

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

IDEF0-модели состоят из документов трех типов:

графических диаграмм,
текста
глоссария.

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

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

Диаграмма верхнего уровня обеспечивает наиболее общее описание объекта моделирования. За этой диаграммой следует серия дочерних диаграмм, дающих более детальное представление об объекте.

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

Рисунок 4. Пример контекстной диаграммы верхнего уровня.

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

Часто бывают случаи, когда отдельные стрелки не имеет смысла продолжать рассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии, или наоборот — отдельные блоки не имеют практического смысла выше какого-то уровня. С другой стороны, иногда возникает необходимость избавиться от отдельных “концептуальных” стрелок и не детализировать их глубже некоторого уровня. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования . Обозначение “туннеля” в виде двух круглых скобок вокруг начала стрелки обозначает, что эта стрелка не была унаследована от функционального родительского блока и появилась (из “туннеля”) только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца стрелки в непосредственной близи от блока - приёмника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта стрелка отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные стрелки не рассматриваются на некоторых промежуточных уровнях иерархии - в таком случае, они сначала “погружаются в туннель”, а затем, при необходимости “возвращаются из туннеля”.

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

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

Функциональная методика IDEF0

Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique). Исторически IDEF0 как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing). Семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=Icam DEFinition), и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST).

Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, "производить услуги"). На диаграмме функциональный блок изображается прямоугольником (рис. 1). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:

· верхняя сторона имеет значение "Управление" (Control);

· левая сторона имеет значение "Вход" (Input);

· правая сторона имеет значение "Выход" (Output);

· нижняя сторона имеет значение "Механизм" (Mechanism).

Рис. 1. Функциональный блок

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

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

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

Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

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

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

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

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

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

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

1) присваивается код каждой зрительной связи. Используется I для входных дуг, С - для связей между дугами управления, О - для связей между выходными дугами, М - для связей между дугами механизма.

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

Данный принцип используется на контекстной диаграмме. Далее полученные там ICOM-коды используются вместо имен данных для сокращения записи.

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

Иногда отдельные интерфейсные дуги высшего уровня не имеет смысла продолжать рассматривать на диаграммах нижнего уровня, или наоборот - отдельные дуги нижнего отражать на диаграммах более высоких уровней – это будет только перегружать диаграммы и делать их сложными для восприятия. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение "туннеля" (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из "туннеля") только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока–приемника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии, – в таком случае они сначала "погружаются в туннель", а затем при необходимости "возвращаются из туннеля".

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

· Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов, создавая модели деятельности подразделений. При этом их интересуют ответы на следующие вопросы:

Что поступает в подразделение "на входе"?

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

Кто является ответственным за выполнение каждой из функций?

Чем руководствуется исполнитель при выполнении каждой из функций?

Что является результатом работы подразделения (на выходе)?

На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели.

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

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

Недостатки IDEF0-диаграмм:

Явно не указаны ни последовательность, ни время;

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

Трудно увязать нескольких процессов.

На рис. 2 приведена диаграмма IDEF0 верхнего уровня бизнес-процесса "Увольнение сотрудника".

Рис. 2. Диаграмма IDEF0 верхнего уровня бизнес-процесса "Увольнение сотрудника".

Контрольные вопросы:

1. В каком году был разработан стандарт IDEF0? В каком году была выпущена последняя его редакция?

2. Что является целью при использовании методологии IDEF0?

3. Какие четыре основных понятия лежат в основе методологииIDEF0?

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

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

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

7. Что хранится в глоссарии?

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

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

10. Какой номер располагается в правом верхнем углу диаграммы?

11. За счет чего достигается структурная целостность IDEF0–модели?

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

13. Использование ICOM-кодов при именовании дуг на диаграммах IDEF0.

14. Туннелирование дуг на диаграммах IDEF0.

15. Какие ограничения сложности приняты для диаграмм IDEF0?

16. Какие этапы выделяют при разработке функциональной модели с помощью IDEF0-диаграмм?

17. Недостатки IDEF0-диаграмм.

ТЕМА: Описание функциональности разработки: диаграммы потоков данных.

Литература: 1. Зелковиц М., Шоу А., Гэннон Дж. Принципы разработки программного обеспечения.

2. Гецци К., Джазайери М., Мандриоли Д. Основы инженерии программного обеспечения.

3. Камаев В. А., Костерин В. В. Технологии программирования.

4. Грекул В.И. Проектирование информационных систем.

Нотация DFD – моделирование потоков данных (процессов) – основа методологии Gane/Sarson, в соответствии с которой модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи объекту или субъекту. Контекстные диаграммы иерархии определяют основные процессы или подсистемы системы с внешними входами и выходами. Они детализируются при помощи диаграмм-потомков. Декомпозиция ведется до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процессы становятся элементарными и детализировать их далее невозможно. Главная цель такого представления - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

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

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

·внешние сущности;

·системы/подсистемы;

·процессы;

·накопители данных;

·потоки данных.

Данный стандарт представлен двумя немного различающихся вариантами, которые называют нотациями. Первая из них называется нотацией Гейна-Сарсана, вторая нотацией Йордона-Де Марко.

Таблица 1. Элементы методологии DFD в нотациях
Гейна-Сарсана и Йордона-Де Марко.

Введение

В 2000 году Международная Организация по Стандартизации (ISO) приняла новую версию стандартов серии 9000 , содержащих перечень требований к системе качества (СК) организации.

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

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

Деятельность организации необходимо представить в виде сети взаимодействующих между собой процессов;

Менеджмент деятельностью организации должен основываться на менеджменте сетью процессов.

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

Представление процессов

В МС ИСО 9000:2000 используется следующее определение процесса:

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

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

Примечание 2. Процессы в организации планируются и исполняются при управляемых условиях для добавления ценности.»

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

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

Процессы вместе с взаимосвязями и взаимодействиями представляют сеть процессов организации.

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

Впервые это обстоятельство было осознано в середине 70-х годов при реализации комплексных проектов по заказам ВВС США. В то же время была предложена и реализована программа комплексной компьютерной поддержки производства (ICAM — Integrated Computer-Aided Manufacturing), в рамках которой, в частности, применялась методология структурного анализа систем. Позже на базе этого подхода была разработана методология функционального моделирования IDEF0, которая в 1993 году была принята в качестве федерального стандарта в США, а в 2000 году — в качестве стандарта в Российской Федерации.

В методологии функционального моделирования IDEF0 для графического представления процесса используется следующая нотация (Рис. 2).

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

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

Модель процессов в рамках СК

Модель сети процессов в рамках системы качества должна отвечать на следующие вопросы:

Какие процессы в деятельности организации относятся к системе качества?

Какова структура этих процессов, включая выходы и потребителей процессов, входы и поставщиков и т.д.?

Как процессы взаимодейтсвуют друг с другом?

Как в рамках процессов выполняются требования, определенные в МС ИСО серии 9000 версии 2000 года?

Требования к функциональной модели

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

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

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

Функциональная модель должна содержать процессы, определенные как обязательные в рамках требований МС ИСО серии 9000 версии 2000 года. Перечень этих процессов приведен в МС ИСО 9001:2000 .

Функциональная модель должна содержать элементы (объекты), регламентируемые в МС ИСО серии 9000 версии 2000 года. Перечень таких элементов приведен в .

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

Особенности функциональной модели СК

Бизнес-процесс

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

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

Таким образом, функциональная модель бизнес-процесса будет охватывать процессы жизненного цикла, а также связанные с ними вспомогательные процессы и процессы менеджмента, входящие в состав деятельности организации. Это полностью согласуется с требованиями МС ИСО семества 9000 версии 2000 года.

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

Обязательные процессы и элементы

В МС ИСО 9001:2000 к обязательным процессам относятся:

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

Менеджмент ресурсов (вспомогательных производственных процессов);

Менеджмент основных производственных процессов (процессов жизненного цикла продукции);

Процессы измерения, контроля и улучшения СК.

К обязательным элементам относятся, в том числе:

Документы, содержащие политику, цели организации в сфере менеджмента качества;

Документы, содержащие ответственность сотрудников организации (должностные инструкции);

Записи качества, и т.д.

Соответственно, функциональная модель должна содержать все обязательные процессы и элементы в соответствии с требованиями МС ИСО серии 9000 версии 2000 года.

В нашем примере бизнес-процесс в швейном ателье будет иметь следующую структуру (Рис. 4).

На диаграмме (Рис. 4) процесс представлен в виде 4-х взаимодействующих между собой процессов. Каждый из 4 процессов является обязательным с точки зрения выполнения требований МС ИСО 9001:2000 .

Стрелки, связывающие функциональные блоки, представляют элементы (объекты), которые передаются с выходов одни процессов на входы других. В том числе, они представляют обязательные с точки зрения МС ИСО 9000:2000 элементы процессов, такие как, например, «Записи качества» или «Политика организации в области менеджмента качества».

Классификация процессов в СК

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

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

Классификация дуг

В рамках IDEF0-модели дуги в зависимости от их положения на диаграмме уже подразделены на 4 категории: входные, выходные, управления и механизма.

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

Материалы, сырье, продукция, ресурсы;

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

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

Стандарты, нормативная документация;

Ответственные исполнители, сотрудники организации и т.д.

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

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

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

Примечание. Графические стили не являются частью методологи IDEF0. Использование графических стилей для классификации процессов впервые было предложено и реализовано в системе IDEF0/EMTool .

Классификация функциональных блоков

Функциональные блоки в IDEF0-модели могут быть классифицированы в зависимости от категорий процессов, которые они представляют. В рамках функциональных моделей СК следует использовать категории процессов, которые регламентированы в МС ИСО 9001:2000 .

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

Заключение

Процессный подход, составляющий основу новой версии МС ИСО 9000:2000, требует применения специальных средств для описания и классификации процессов, составляющих деятельность организации.

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

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

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

А. Г. Курьян, П. С. Серенков

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

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

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

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

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

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

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

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

корпоративный налоговый контроль (самоконтроль).

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

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

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

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

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

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

– более полно учесть изменения внешней среды,

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

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

– повысить при минимальных затратах финансовую устойчивость и стоимость предприятия.

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

Из книги Налоговый менеджмент автора Барулин С В

Глава 1. Теория налогового менеджмента

Из книги Обеспечение информационной безопасности бизнеса автора Андрианов В. В.

Из книги Управление рисками, аудит и внутренний контроль автора Филатов Александр Александрович

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

Из книги Основы менеджмента автора Мескон Майкл

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

Из книги автора

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

Из книги автора

4. Оптимизация налогов организациями в рамках корпоративного налогового менеджмента 4.1. Способы оптимизации налогов Способы налоговой оптимизации разнообразны по своей природе. Среди наиболее популярных методов оптимизации налогов специалисты обычно выделяют: метод

Из книги автора

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

Из книги автора

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

Из книги автора

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

Из книги автора

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

Из книги автора

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

Из книги автора

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

Из книги автора

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

Из книги автора

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

Налоговый менеджмент в системе управления корпоративными финансами. Налоговый менеджмент

Налоговый менеджмент в системе управления корпоративными финансами. Налоговый менеджмент

Функциональная методика IDEF0

Функциональная методика IDEF0

Введение

Представление процессов

Модель процессов в рамках СК

Требования к функциональной модели

Особенности функциональной модели СК

Классификация процессов в СК

Классификация дуг

Классификация функциональных блоков

Заключение