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

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

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

Группы задач «Маркетинг» и «Исследования» имеют различные цели. Однако проблемы, возникающие при их решении, имеют много общего. Их можно сгруппировать по следующим типам [5].

- Многочисленные разнообразные специальные методы маркетинга. Комплексное изучение всех этих методов – сложнейшая задача. - Большая роль методов творчества. - Сложность объекта управления: большое количество учитываемых факторов, многокритериальность задач принятия решений; субъективность многих оценок. - Объект исследования ментальной природы. Исследования проводятся на стыке с психологией и социологией, то есть используется арсенал методов смежных наук. - Большая роль информационных технологий. - Информационная закрытость многих рынков, особенно B2B.

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

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

69. Коренная перестройка — в этом, прежде всего, суть реинжиниринга бизнес-процессов. Слово «перестройка» здесь как нельзя лучше ассоциируется с той перестройкой, которую пережил в 1985 — 1991 годах Советский Союз. Правда, супердержава не выдержала такой «встряски» и неожиданно для себя и всего мира развалилась. 10-летний опыт практического реинжиниринга в развитых странах свидетельствует о том, что примерно 50-70% компаний, проводивших реинжиниринг своих бизнес-процессов, если и не «развалились», то не добились тех существенных результатов, ради которых и стоило подвергать себя столь сильному «стрессу». Однако остальные 30-50% компаний, имевших мужество «перейти Рубикон», отделявший уютную и надежную гавань их бизнеса от штормов и ураганов океана жесткой конкурентной борьбы, показали всему миру, что «игра стоит свеч», добившись скачкообразного увеличения показателей эффективности функционирования бизнеса. В ближайшей перспективе все фирмы, независимо от их желания и степени осознания необходимости глубоких внутренних перемен, обусловленных объективными неотвратимыми динамичными изменениями внешней деловой среды, «обречены», во избежание исчезновения, на реинжиниринг своих бизнес-процессов.

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

Реинжиниринг бизнес-процессов не предполагает осуществления постоянных, но незначительных изменений, ведущих к небольшому «приростному» (на единицы и даже десятки процентов) улучшению показателей функционирования компании. В результате успешно проведенного реинжиниринга — быстрого осуществления глубоких и всесторонних коренных изменений системы управления — компания достигает существенного, «прорывного» роста эффективности (в десятки и сотни раз). Поэтому реинжиниринг можно поставить в один ряд с таким фундаментальным открытием в области организации и управления производством как сформулированный еще в 1776 году Адамом Смитом в его книге «Богатство народов» принцип разделения труда, позволивший на основе глубокой специализации и разделения процесса производства на множество элементарных операций достичь стократного и более роста производительности труда. Специфика реинжиниринга состоит в том, что существующая более 250 лет узкая специализация и обусловленная ею многократная передача ответственности как в производстве, так и, особенно, в управлении, отжили свой век и реинтегрируются ныне в сквозные бизнес-процессы, ответственность за которые от начала и до конца берут на себя сплоченные командным духом группы единомышленников, способные выполнять широкий спектр работ. Причем, работа в команде предполагает не столько всеобщий и постоянный «одобрямс» и умиление по поводу любых действий ее членов, сколько творческие дискуссии и столкновение мнений с целью выработки наилучших нестандартных решений. Как говорил знаменитый шотландский философ и экономист Дэвид Юм (1711 — 1776): «Истина возникает в результате разногласий между друзьями».

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

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

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

К моделям проблемных областей предъявляются следующие требования:

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

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

реализуемость, подразумевающая наличие средств физической реализации модели проблемной области в ЭИС;

обеспечение оценки эффективности реализации модели проблемной области на основе определенных методов и вычисляемых показателей.

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

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

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

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

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

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

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

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

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

Главный критерий адекватности структурной модели проблемной области заключается в функциональной полноте разрабатываемой ЭИС.

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

время решения задач;

стоимостные затраты на обработку данных;

надежность процессов;

косвенные показатели эффективности, такие, как объемы производства, производительность труда, оборачиваемость капитала, рентабельность и т.д.

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

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

Рассмотрим особенности построения моделей проблемной области на трех уровнях детализации.

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

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

К моделям предметных областей предъявляются следующие требования:

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

– понятность для заказчиков и разработчиков на основе применения графических средств отображения модели;

– реализуемость, подразумевающая наличие средств физической реализации модели предметной области в ИС;

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

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

Структурный аспект предполагает построение:

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

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

– структуры управления, отражающей события и бизнес-правила, которые воздействуют на выполнение процессов;

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

– технической структуры, описывающей структуру комплекса технических средств.

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

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

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

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

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

– время решения задач;

– стоимостные затраты на обработку данных;

– надежность процессов;

– косвенные показатели эффективности, такие, как объемы производства, производительность труда, оборачиваемость капитала, рентабельность и т.д.

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

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

– на внешнем уровне (определении требований);

– на концептуальном уровне (спецификации требований);

– на внутреннем уровне (реализации требований).

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

Рассмотрим особенности построения моделей предметной области на трех уровнях детализации.

Объектная структура

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

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

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

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

Функциональная структура

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

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

На внешнем уровне моделирования определяется список основных бизнес-функций или видов бизнес-процессов. Обычно таких функций насчитывается 15–20.

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

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

Структура управления

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

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

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

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

На внутреннем уровне выполняется формализация бизнес-правил в виде триггеров или вызовов программных модулей.

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

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

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

На концептуальном уровне для каждого подразделения задается организационно-штатная структура должностей (ролей персонала).

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

Техническая структура

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

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

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

На внутреннем уровне строится, например, модель «клиент-серверной» архитектуры вычислительной сети.

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

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

Структурным анализом принято называть метод исследования системы, которое начинается с ее общего обзора, а затем детализируется, приобретая иерархическую структуру с все большим числом уровней. Для таких методов характерно: разбиение на уровни абстракции с ограниченным числом элементов (от 3 до 7); ограниченный контекст, включающий только существенные детали каждого уровня; использование строгих формальных правил записи; последовательное приближение к результату. Структурный анализ основан на двух базовых принципах – «разделяй и властвуй» и принципе иерархической упорядоченности. Решение трудных проблем путем их разбиения на множество меньших независимых задач (так называемых "черных ящиков") и организация этих задач в древовидные иерархические структуры значительно повышают понимание сложных систем. Определим ключевые понятия структурного анализа.

Операция – элементарное (неделимое) действие, выполняемое на одном рабочем месте.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 3. 16 Типичная функциональная структура управления

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

1. Стимулирование деловой и профессиональной специализации.

2. Уменьшение дублирования усилий и потребления материальных ресурсов в функциональных областях.

3. Улучшение координации в функциональных областях.

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

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

74. Структура управления — институциональное образование, в рамках которого обеспечивается целостность транзакций.^[1] Могут применять к понятию Структура управления организацией, фирмой, предприятием или любым другим юридическим лицом. Существует 3 основополагающих элемента структуры управления:

1. Звено — должность, специализация или подразделение.

2. Связи — промежуточный связующий компонент структуры между всеми элементами

3. Уровни управления