  ФЕДЕРАЛЬНОЕ АГЕНТСТВО ЖЕЛЕЗНОДОРОЖНОГО ТРАНСПОРТА
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ОБРАЗОВАНИЯ
«ОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ПУТЕЙ СООБЩЕНИЯ» (ОмГУПС (ОмИИТ))
Кафедра «Автоматика и система управления»
АРХИТЕКТУРА ПРЕДПРИЯТИЯ ООО «Маркетинговое агентство «Делфи - 2000»
Пояснительная записка к курсовой работе
ИНМВ.300000.000 ПЗ
по дисциплине Архитектура предприятия (продвинутый уровень)
Студентка гр.__25F_______________
(номер группы)
____________ __В.М. Жикиина__
(подпись студента) (И., О., Фамилия студента)
____________
(дата)
Руководитель –
__к. т. н., доцент кафедры «АиСУ»___
(должность преподавателя)
________________ _А.В.Красулин_
(подпись преподавателя) (И., О., Фамилия преподавателя)
________________
(дата)
___________
(оценка)
Омск 2016
Реферат
УДК 681.3.06
Пояснительная записка к курсовой работе содержит 32 страницы, 12 рисунков, 7 источников.
Ключевые слова: архитектура предприятия, бизнес-процесс, бизнес-архитектура, бизнес-модель, модель предприятия.
Объект исследования: ООО «Маркетинговое агентство «Делфи – 2000»
Предмет исследования: основные бизнес-процессы и структура компании.
Цель курсовой работы рассмотрение особенностей построения архитектуры предприятия.
В процессе разработки были изучены основные возможности Business Studio 4.0 и процесс построения структуры организации.
Пояснительная записка выполнена в текстовом редакторе Microsoft Word 2010, демонстрационные листы выполнены в пакете Business Studio 4.0.
Содержание
Введение……………………………………………………………………….…..3
1 Архитектура предприятия и принципы ее построения……………………..5
1.1 Понятие, значение и основные элементы архитектуры предприятия.......5
1.2 Принципы построения архитектуры предприятия………………………..9
1.3 Построение функциональной модели предприятия. Модель AS-IS……14
2 Характеристика ООО «Маркетинговое агентство «Делфи - 2000»………20
2.1 Характеристика деятельности ООО «МА «Делфи – 2000». Миссия и стратегическое планирование…………………………………………………20
2.2 Бизнес-архитектура ООО «МА «Делфи-2000»………………………….22
3 Построение системной архитектуры предприятия………………………..25
Заключение……………………………………………………………………..30
Список использованных источников…………………………………………31
Введение
Современное предприятие можно представить в виде двух взаимосвязанных составляющих: бизнеса и информационных технологий, его поддерживающих. Обе эти составляющие сегодня достаточно сложны и многогранны.
Современный бизнес – это совокупность постоянно возрастающего количества процессов во всей их сложности, широкий спектр предоставляемых услуг и продуктов, территориальная распределённость, растущее количество регламентирующих документов.
На сегодняшний день информационные технологии вносят весомый вклад в управление предприятием.
Сегодня все больше руководителей и аналитиков начинают испытывать потребность в комплексном описании и планировании развития своей организации. Это им нужно как минимум для того, чтобы знать, что их организация представляет собой в реальности, поддерживать рациональный порядок ее устройства, а затем — приступить к ее планомерному развитию или трансформации с учетом всех важных обстоятельств. Таким целям служит «Архитектура предприятия» (АП, Enterprise Architecture) — важнейшая комплексная дисциплина нового времени. В мире наблюдается настоящий бум работ в этой области, в штатных расписаниях позиция «Enterprise Architect» заняла устойчивое положение, ведущие университеты разработали углубленные курсы и выпускают квалифицированных специалистов данного профиля. При построении архитектуры предприятия, в частности, системной архитектуры, возникает немало традиционных вопросов. Все они имеют ответ, но любой ответ становится знанием предприятия только в том случае, если он задокументирован. Практически все известные методологии и стандарты (от отечественных ГОСТов и SADT до RUP) и инструменты (начиная с IDEF Designer, System Architect и BPwin/Erwin и заканчивая продуктами семейства Rational) предоставляют возможности для документирования только части из перечисленных знаний, поскольку ориентируются в значительной степени на разработку программных систем. Многие же из перечисленных выше вопросов лежат в слое бизнес-архитектуры.
Целью данной работы является рассмотрение особенностей построения архитектуры предприятия.
Для достижения цели поставлены задачи:
изучить основные модели и методы управления организацией на основе архитектурных подходов;
дать методологические основы выбора и применения методов повышения эффективности деятельности путем применения инструмента архитектуры предприятия;
освоить основные принципы построения архитектуры предприятия и ее отдельных доменов;
уметь пользоваться основными методическими приемами различных архитектурных подходов.
Объектом исследования является ООО «Маркетинговое агентство «Делфи – 2000».
Предметом исследования основные бизнес-процессы и структура компании.
1 Архитектура предприятия и принципы ее построения
Понятие, значение и основные элементы архитектуры предприятия
Архитектура предприятия становится информационной основой корпоративной структуры компании. Она преследует две цели: во-первых, дать подробное системное описание самой организации для поддержания порядка ее функционирования, а, во-вторых, иметь стратегический план развития компании, учитывающий существующее внешнее окружение компании и ее техническую и технологическую оснащенность.
Архитектура предприятия представляет собой процесс сбора и распространения информации о том, как организация использует и должна использовать ИТ в своей деятельности [1]. По сути, архитектура предприятия представляет собой информационную основу корпоративной структуры компании. Непосредственно архитектура предприятия не описывает конкретные технические решения отдельных информационных систем, но позволяет получить существенную выгоду для бизнеса организации в целом, что связано с повышением степени использования и эффективности информационных систем и программных продуктов, стандартизацией и повторным использованием ИТ-ресурсов, а также снижением рисков инвестиций в ИТ-сфере.
В настоящее время существует несколько широко применяемых определений данного понятия. В качестве рабочего предлагается использовать следующее определение: архитектура предприятия – это всестороннее описание (модель) всех его ключевых элементов и связей между ними (включая бизнес-процессы, технологии и информационные системы), а также процесс поддержки изменения бизнес-процессов предприятия со стороны информационных технологий [3].
Для целей системного анализа архитектура предприятия может рассматриваться в двух аспектах:
статическом - по состоянию предприятия в некоторый фиксированный момент времени;
динамическом - как процесс перехода (миграции) предприятия от текущего состояния к некоторому желаемому состоянию в будущем.
Рассматриваемая в статике архитектура предприятия состоит из следующих элементов:
миссия и стратегия, стратегические цели и задачи;
бизнес-архитектура;
системная архитектура [6].
Рассматриваемая в динамике архитектура предприятия — это логически связанный цельный план действий и скоординированных проектов, необходимых для преобразования сложившейся архитектуры организации к состоянию, определенному как долгосрочная цель, базирующийся на текущих и планируемых бизнес-целях и бизнес-процессах организации.
Таким образом, архитектура предприятия в общем случае описывается следующими последовательно зависимыми разделами:
сформулированные миссия и стратегия предприятия, стратегические цели и задачи;
бизнес-архитектура в текущем (as is) и планируемом (to be) состоянии;
системная архитектура в текущем (as is) и планируемом (to be) состоянии;
планы мероприятий и проектов по переходу из текущего состояния в планируемое (рис. 1).
На рисунке показано, что выполнение плана миграции не означает замораживания развития бизнес- и системной архитектуры.
Системная архитектура
Бизнес-архитектура
План миграции
Миссия, стратегия, цели и задачи
Архитектура предприятия
Рисунок 1 Циклическое развитие архитектуры предприятия
Таким образом, планируемая системная архитектура является архитектурой «to be» только на определенном витке развития предприятия. Одновременно возврат к стратегическому уровню миссии и стратегических целей и задач не означает необходимость пересмотра миссии и стратегии. Но в конце каждого цикла обязательно проводится анализ эффективности разработанных и осуществленных мероприятий, при необходимости при второй итерации корректируются бизнес-архитектура, системная архитектура, реализуются новые планы миграции. В каждый момент времени может быть несколько циклов, каждый такой цикл не обязательно затрагивает все предприятие в целом, цикл может затрагивать отдельные направления, отдельные вопросы бизнеса и может быть зафиксирован в виде отдельного проекта.
При поэтапном плане миграции для фиксации достигнутых результатов возможно построение промежуточных (миграционных) одной или нескольких архитектур.
Миссия, стратегия и бизнес-цели определяют направления развития предприятия и ставят долгосрочные цели и задачи [6].
Бизнес-архитектура на основании миссии, стратегии развития и долгосрочных бизнес-целей определяет необходимые организационную структуру, структуру каналов продаж и функциональную модель предприятия, документы, используемые в процессе разработки и реализации продуктов. Функциональная модель описывает бизнес-процессы, направленные на реализацию текущих задач и перспективных целей.
Бизнес-архитектура включает в себя:
предлагаемые и планируемые к реализации предприятием продукты и услуги (включая индивидуальные схемы их производства), формализованные в виде единого реестра продуктов и услуг, содержащего также клиентскую сегментацию, тарифы и владельцев продуктов;
каналы продажи продуктов и услуг, построенные как на базе структурных и территориальных подразделений предприятия, так и на базе современных информационных технологий;
функции и процессы по реализации внешних и внутренних продуктов и услуг, образующие деревья функций и процессов (далее - бизнес-функции и бизнес-процессы);
финансовые и распорядительные документы (как в бумажном, так и в электронном виде), формализованные в виде единого реестра (альбома форм) документов предприятия;
документопотоки, определяемые нормативными актами по внутреннему и внешнему документообороту;
организационную структуру, включая штатное расписание предприятия и его территориальных подразделений, являющихся самостоятельными хозяйствующими единицами (юридическими лицами), комитеты, рабочие группы и ролевые функции отдельных сотрудников, должностные инструкции, положения о подразделениях и рабочих органах и другие документы, регламентирующие взаимоотношения и распределение ответственности между сотрудниками, а также между структурными подразделениями [1].
Системная архитектура (ИТ-архитектура, архитектура ИС предприятия) — определяет совокупность технологических и технических решений для обеспечения информационной поддержки работы предприятия в соответствии с правилами и концепциями, определенными бизнес-архитектурой.
Планы миграции определяют сценарий перехода предприятия от текущего состояния к перспективному, определяемому стратегическими целями и задачами. Планы миграции определяют преобразования как бизнес-, так и системной архитектуры. При поэтапной миграции для целей формализации промежуточных результатов разрабатываются промежуточные (миграционные) одна или несколько бизнес- и системных архитектур. Планы миграции в соответствии с принятой на предприятии методологией управления проектами формализуются в виде отдельных проектов, включающих, в частности:
определение проекта как совокупности задач и работ;
фазы и сроки реализации проекта в целом и составляющих проект задач и работ;
анализ конкурентной среды и рисков, связанных с реализацией проекта;
состав статей расхода бюджета проекта;
критерии успешности реализации проекта и ожидаемый экономический эффект.
Принципы построения архитектуры предприятия
В литературе широко освещены следующие методологии построения АП: модель Захмана, метод EAP (Enterprise Architecture Planning) С. Спивака, TOGAF, методика META Group, методология Gartner, FEAF; DoDAF и т.д. Несмотря на наличие значительного числа методик по созданию АП, ни одна из них не имеет доминирующего положения на рынке. Каждая из них по-своему удобна, понятна и имеет как «плюсы», так и «минусы».
Большинство организаций имеют достаточно широкие определения того, что является бизнес-архитектурой и бизнес-моделями. Бизнес-архитектура является областью, которая определяется высшими руководителями, отвечающими за основные функции (бизнес) организации. Как правило, она включает в себя утверждения по поводу миссии и целей организации, критические факторы успеха, бизнес-стратегии, описания функций, а также структуры и процессы, необходимые для реализации функций.
Ключом к построению хорошей бизнес-архитектуры является определение бизнес-процессов, их функций и характеристик. Это становится основой для построения архитектуры приложений, которые обеспечивают эти процессы [5].
Таким образом, можно сказать, что бизнес-архитектура включает в себя, как правило, следующие аспекты:
бизнес-стратегия, функции и организационные структуры – собрание целевых установок, планов и структур организации. Данная информация может быть представлена в самых разных форматах, но наиболее важный аспект состоит в создании контекста для описания бизнес-процессов. Эта часть архитектуры не является технической, но она критически важна с той точки зрения, что архитектура информационных технологий (информации, прикладных систем, технологическая архитектура) строится на ее основе и обеспечивает реализацию ключевых функций организации;
архитектура бизнес-процессов, которая определяет основные функциональные области организации. Для министерства – это могут быть функции, перечисленные в Положении о министерстве, для коммерческой организации – процессы разработки новых продуктов, услуг и сбыта товаров и т.п. Она также описывает специфические процессы внутри каждой функциональной области и их операционные параметры – например, объемы операций, роли, реализацию централизованной или децентрализованной модели операций и т.д. Эта часть является как бы "точкой соприкосновения" между бизнес-архитектурой и архитектурой приложений и обеспечивает взгляд на бизнес и функции организации, достаточно детализированный для того, чтобы использовать его при выработке стратегии и планов создания приложений;
показатели эффективности. Этот аспект состоит в определении ключевых показателей эффективности (КПЭ) работы организации, их текущих уровней и желаемых, будущих уровней и включает в себя также разработку на верхнем уровне модели КПЭ для мониторинга.
"Если архитектура ИТ предприятия описывает то, как компоненты ИТ объединяются вместе для достижения нужного результата, то точно также бизнес-архитектура описывает, как элементы бизнеса соединены вместе" .
Построение бизнес-архитектуры начинается с общего обзора ситуации, который предполагает поиск ответов на следующие вопросы:
Каков внешний контекст деятельности организации?
В чем состоят основные функции и добавочная стоимость, которая является итогом деятельности организации?
Какие сценарии развития бизнеса необходимо учитывать, и какова вероятность их реализации?
Какие необходимы информационные взаимосвязи и процессы обработки информации?
Рисунок 2 Контекст бизнес-архитектуры
Независимо от выбранной методики построения архитектуры предприятия необходимо понимать, что построение архитектуры – это циклический процесс. Управление меняющимися бизнес-процессами и адаптацией к ним корпоративной системы предприятия должно превратиться в «рутинную» деятельность, поскольку фактически управление предприятием – это есть управление архитектурой предприятия в контексте достижения наибольшей эффективности его функционирования.
Усилия по построению бизнес-архитектуры, которая представляется в виде бизнес-моделей, быстро окупают себя и имеют большое количество дополнительных преимуществ. Под бизнес-моделями понимается динамический поток событий, связанных с бизнесом, в который вовлечены различные функции бизнеса, организационные единицы и активы предприятия. Возможная отдача от реализации таких моделей достаточно подробно изучалась и описывалась на протяжении последнего столетия. Основная проблема состоит в том, чтобы убедить руководство в этих преимуществах и добиться от него поддержки проведения проекта разработки бизнес-моделей. А преимущества от построения таких моделей лежат в двух плоскостях: дополнительных возможностях для бизнеса и уменьшении затрат. По оценкам, создание бизнес-моделей и связанная с этим оптимизация затрат даже без радикальных изменений бизнеса может дать до 10% экономии. А при моделировании альтернативных вариантов бизнес-процессов организации могут сэкономить до 20%. Но не менее важная роль бизнес-моделей состоит в том общем языке, которые они дают представителям бизнеса и ИТ в обсуждении соответствующих возможностей.
Важную роль в процессе формирования целевой архитектуры предприятия играют модели бизнес-процессов. На самом деле, обеспечение соответствия между ключевыми бизнес-процессами и архитектурой информационных технологий является самой важной составляющей всех усилий по созданию архитектуры. Эти модели также могут быть реализованы различными способами, т.е. являются описательными или исполняемыми, качественными или количественными и т.п. Они могут применяться как на исключительно "бизнес-уровне" для оптимизации соответствующих процессов, так и для облегчения взаимопонимания между бизнес-пользователями и специалистами в области ИТ. Обычно в организации имеется 10-20 основных процессов. Предложенные ниже методики помогают реализовать самый трудный начальный этап описания и документирования этих процессов. Подчеркнем, что бессмысленно разрабатывать детальные модели подпроцессов для всех основных процессов. Важно сосредоточиться на тех из них, которые будут подвергнуты изменениям.
Gartner рекомендует начать с построения высокоуровневых моделей бизнес-процессов предприятия. Начальным этапом для этого является определение классов бизнес-процессов. Под классом бизнес-процессов понимается группа процессов, которые состоят из большого числа одинаковых бизнес-активностей. Далее рекомендуется выполнить следующие шаги.
Шаг 1. Идентификация критически важных для предприятия процессов (обычно не более восьми).
Хорошими кандидатами для включения в рамки архитектуры предприятия являются те ключевые процессы, которые максимально влияют на способности организации реализовывать свою миссию, достигать цели, выполнять основные функции, а также следующие процессы:
процессы, которые открывают новые возможности, например, новые каналы предоставления услуг;
процессы, которые в настоящее время выполняются плохо и являются источниками неудовлетворенности клиентов;
процессы, в которых имеются возможности для экономии.
Желательно, чтобы рекомендуемое число таких процессов, не превышало "волшебного числа" 8 в соответствии с известным принципом: "семь плюс-минус два" объекта. При необходимости схожие бизнес-процессы могут быть объединены в группы или классы.
Шаг 2. Отследить связи между этими процессами и бизнес-стратегиями, движущими силами и критически важными факторами успеха. Это можно сделать с помощью матрицы взаимных связей. Для каждого элемента этой матрицы определяется качественная оценка по принципу "важно" – "неважно" или по некоторой условной шкале. Например, можно использовать так называемую шкалу 9-3-1, в соответствии с которой 9 обозначает сильную взаимосвязь, 3 – промежуточную, 1 – слабую.
Шаг 3. Построить модели высокого уровня для ключевых бизнес-процессов (см. следующий раздел). Это включает последовательность основных шагов (желательно, не более восьми на процесс).
Шаг 4. Для каждого шага процессов, идентифицированных на этапе 3, определить ответственных за выполнение шага. Это может быть функциональное подразделение внутри организации, партнер, клиент, внешний регулирующий орган.
Шаг 5. Идентифицировать и документировать основные категории информационных объектов (опять же рекомендуется не более восьми).
Такое небольшое количество высокоуровневых моделей и понимание их связей с ключевыми факторами и факторами успеха позволяет понять в целом деятельность организации и использование ИТ-ресурсов[1].
Построение функциональной модели предприятия. Модель AS-IS
При разработке функциональной модели (определении функциональных требований) может возникнуть множество проблем:
заказчик не может точно выразить, решение каких задач возлагается на информационную систему. Зачастую заказчик даже не знает, что такое требование и как его формулировать;
представители заказчика (начальники разных уровней, эксперты-технологи, рядовые пользователи) по-своему видят работу будущей системы и часто их требования к системе носят взаимоисключающий характер. Особенно характерна такая ситуация, когда разрабатываемая система будет внедряться на нескольких объектах автоматизации;
заказчик зачастую не знает возможностей современных вычислительных систем и стремится рассматривать процесс автоматизации как простой перенос элементарных видов деятельности, выполняемых вручную, на компьютеры. При этом он не задумывается об оптимизации бизнес-процессов внутри организации с приходом новых технологий;
заказчик не верит в возможность выполнения некоторых функций «бездушными» машинами.
Построение функциональной модели должно решить большую часть этих проблем [2].
При ее разработке сначала строится модель существующей организации работы AS-IS (как есть) на основе должностных инструкций, приказов, отчетов, нормативной документации и т. д. Она позволяет выяснить, «что мы делаем сегодня» перед тем, как «перепрыгнуть» на то, «что мы будем делать завтра» [3]. Анализ модели позволяет понять, где находятся слабые места, в чем будут состоять преимущества новых процессов и насколько глубоким изменениям подвергнется существующая организация деятельности предприятия (компании, отдела). Признаками неэффективной организации деятельности могут быть:
бесполезные, неуправляемые и дублирующие работы;
работы без результата;
неэффективный документооборот (нужный документ не оказывается в нужное время в нужном месте) и т. д.
Найденные в модели недостатки исправляются при создании модели TO-BE (как будет) – модели новой организации работы предприятия. Модель TO-BE нужна для анализа альтернативных путей решения задачи и выбора наилучшего из них.
Построение системы на основе модели AS-IS приводит к автоматизации предприятия по принципу «все оставить как есть, только чтобы компьютеры стояли», т. е. система будет автоматизировать несовершенные бизнес-процессы и дублировать, а не заменять существующий документооборот. В результате внедрение и эксплуатация такой системы приводит лишь к дополнительным издержкам на закупку оборудования, создание программного обеспечения и их сопровождение.
Построение системы на основе модели SHOULD-BE приводит к тому, что такая система просто не будет использоваться.
Таким образом, наиболее эффективная технология построения функциональной модели заключается в разработке модели TO-BE на основе предварительно построенных моделей AS-IS и SHOULD-BE.
В настоящее время двумя наиболее популярными методологиями построения функциональных моделей являются SADT и DFD.
Методология SADT (Structured Analysis and Design Technique – методология структурного анализа и проектирования) представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели системы [5].
Стоит отметить, что SADT (IDEF0) рекомендована для использования Госстандартом РФ и активно применяется в отечественных госструктурах (например, в Государственной налоговой инспекции РФ).
Данная методология при описании функционального аспекта информационной системы конкурирует с методами, ориентированными на потоки данных (DFD). В отличие от них IDEF0 позволяет:
описывать любые системы, а не только информационные (DFD предназначена для описания программного обеспечения);
создать описание системы и ее внешнего окружения до определения окончательных требований к ней. Иными словами, с помощью данной методологии можно постепенно выстраивать и анализировать систему даже тогда, когда трудно еще представить ее воплощение [2].
Таким образом, IDEF0 может применяться на ранних этапах создания широкого круга систем. В то же время она может быть использована для анализа функций существующих систем и выработки решений по их улучшению.
Основу методологии IDEF0 составляет графический язык описания процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.
Модель (AS-IS, TO-BE или SHOULD-BE) может содержать 4 типа диаграмм [5]:
контекстная диаграмма показывает назначение системы (основную функцию) и ее взаимодействие с внешней средой;
диаграммы декомпозиции предназначены для детализации функций и описания каждой подсистемы и их взаимодействия;
диаграммы дерева узлов показывают иерархическую зависимость функций (работ);
диаграммы только для экспозиции (for exposition only, FEO) строятся для иллюстрации отдельных фрагментов модели с целью отображения альтернативной точки зрения на происходящие в системе процессы (например, с точки зрения руководства организации).
Методология IDEF0 отличается простой графической нотацией, используемой для построения модели. Главными компонентами модели являются диаграммы. На них отображаются функции системы в виде прямоугольников, а также связи между ними и внешней средой посредством стрелок. Использование всего лишь двух графических примитивов (прямоугольник и стрелка) позволяют быстро объяснить правила и принципы построения диаграмм IDEF0 людям, незнакомым с данной методологией. Это достоинство позволяет подключить и активизировать деятельность заказчика по описанию бизнес-процессов с использованием формального и наглядного графического языка.
Основные элементы графической нотации IDEF0 представлены на рисунке 5.
|
