Размещено на http://www.allbest.ru/

Федеральное агентство железнодорожного транспорта

Федеральное государственное бюджетное образовательное учреждение высшего образования

«Омский государственный университет путей сообщения»

(ОмГУПС (ОмИИТ))

Кафедра «Автоматика и системы управления»

Пояснительная записка к курсовой работе по дисциплине

«Архитектура предприятия (продвинутый уровень)»

Архитектура предприятия «АКонцепт»

Студентка гр. 25 f

Т.П. Карбушева

Руководитель - к. т. н.,

доцент кафедры АиСУ

А.В. Красулин

Омск 2016



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

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

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

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



1. Приемлемость и охват типов объектов предприятия. Проектирование предприятия и работа предприятия

1.1 Понятие архитектуры предприятия

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

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

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

- структуру бизнеса;

- информацию, необходимую для ведения бизнеса;

- технологии, применяемые для поддержания бизнес-операций;

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

1.2 Значение архитектуры предприятия в современных условиях

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

- оказание помощи менеджерам при анализе потенциальных изменений и их реализации;

- предоставление основы для совместной работы бизнес-менеджеров и ИТ-менеджеров над целями, бизнес-процессами и системной организацией;

- предоставление единого хранилища всей информации о предприятии;

- обеспечение менеджерам поддержки в принятии решений.

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

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

Итак, имеется три причины, обуславливающие необходимость использования архитектурного подхода [4]:

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

- включение ИТ в основную деятельность, рост требований к эффективности инвестиций в ИТ;

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

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

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

- выявление первоочередных направлений совершенствования каналов связи;

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

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

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

- анализ альтернативных вариантов совершенствования ИТ-инфра-структуры;

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

- выявление бизнес-процессов, требующих совершенствования;

- избавление от дублирующих действий в различных системах;

- анализ альтернативных вариантов совершенствования бизнес процессов;

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

1.3 Основные элементы и слои архитектуры предприятия

Концепция слоев - одна из общеупотребительных моделей, используемых разработчиками программного обеспечения для разделения сложных систем на более простые части. В архитектурах компьютерных систем, например, различают слои кода на языке программирования, функций операционной системы, драйверов устройств, наборов инструкций центрального процессора и внутренней логики микросхем. В среде сетевого взаимодействия протокол FТР работает на основе протокола ТСР, который, в свою очередь, функционирует «поверх» протокола IР, расположенного «над» протоколом Ethernet. Итак, рассмотрим основные причины интереса к слоям архитектуры программных систем.

Первая причина заключается в том, что слои формализуются. Интуитивно понятно, что если система разбита на ряд слоев, то слой n - это компонент или набор компонентов системы, которые используют только компоненты слоя n-1 и могут быть использованы только компонентами слоя n+1.

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

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

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

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

Помимо преимуществ, система архитектурных слоев обладает и определенными недостатками.

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

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

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

- статическом - по состоянию в некоторый фиксированный момент времени;

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

Рассматриваемая в статике архитектура предприятия состоит из следующих элементов:

- миссия и стратегия, стратегические цели и задачи;

- бизнес-архитектура;

- системная архитектура.

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

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

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

- бизнес-архитектура в текущем (as is) и планируемом (to be) состоянии;

- системная архитектура в текущем (as is) и планируемом (to be) состоянии;

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

Таким образом, планируемая системная архитектура является архитектурой «to be» только на определенном витке развития предприятия.

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

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

В архитектуре предприятия следует выделять следующие слои:

- фронт-офис;

- мидл-офис;

- бэк-офис.

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

- получение и ввод для последующей обработки первичных документов;

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

- обзвон клиентов и рассылка клиентам информационных сообщений;

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

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

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

- подразделение проверки заемщиков в службе безопасности;

- подразделение управления рисками.

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

- система ведения позиционного учета;

- система проверки заемщика в бюро кредитных историй;

- система расчета скорингового балла по кредитной заявке.

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

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

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

- информационное хранилище (DWH);

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

Примеры систем отчётности:

- система управленческой отчётности;

- система аналитической отчётности;

- система ключевых показателей эффективности подразделений предприятия;

структурный проектирование архитектура ориентированность

1.4 Общие принципы построения архитектуры предприятия

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

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

Рисунок 1 - базовая схема архитектуры предприятия, предложенная NIST



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

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

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

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

- новые потребности клиентов;

- новые возможности информационных технологий;

- новые угрозы со стороны внешней среды.

1.5 Построение функциональной модели предприятия с использованием методологий структурного анализа и проектирования. Модель AS-IS

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

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

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

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

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

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

Построение функциональной модели должно решить большую часть этих проблем.

При ее разработке сначала строится модель существующей организации работы AS-IS (как есть) на основе должностных инструкций, приказов, отчетов, нормативной документации и т. д. Она позволяет выяснить, «что мы делаем сегодня» перед тем, как «перепрыгнуть» на то, «что мы будем делать завтра». Анализ модели позволяет понять, где находятся слабые места, в чем будут состоять преимущества новых процессов и насколько глубоким изменениям подвергнется существующая организация деятельности предприятия (компании, отдела). Признаками неэффективной организации деятельности могут быть:

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

- работы без результата;

- неэффективный документооборот (нужный документ не оказывается в нужное время в нужном месте) и т. д.

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

Следует указать на распространенную ошибку при создании модели TO-BE - это создание идеализированной модели. Примером может служить создание модели на основе знаний руководителя, а не конкретного исполнителя работ. Руководитель знаком с тем, как предполагается выполнение работы по руководствам и должностным инструкциям и часто не знает, как на самом деле подчиненные выполняют работы. В результате получается приукрашенная, искаженная модель, которая несет ложную информацию и которую невозможно в дальнейшем использовать для анализа. Такая модель называется SHOULD-BE (как должно было быть).

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

Построение системы на основе модели SHOULD-BE приводит к тому, что такая система просто не будет использоваться.

Таким образом, наиболее эффективная технология построения функциональной модели заключается в разработке модели TO-BE на основе предварительно построенных моделей AS-IS и SHOULD-BE.

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

Методология SADT (Structured Analysis and Design Technique - методология структурного анализа и проектирования) представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели системы.

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

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

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

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

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

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

Модель (AS-IS, TO-BE или SHOULD-BE) может содержать 4 типа диаграмм:

- контекстную диаграмму;

- диаграммы декомпозиции;

- диаграммы дерева узлов;

- диаграммы только для экспозиции (for exposition only, FEO).

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

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

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

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

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

Рассмотрим основные элементы графической нотации IDEF0 (рисунок 2).



Рисунок 2 - Элементы графической нотацииIDEF0

Прямоугольник представляет собой работу (процесс, деятельность, функцию или задачу), которая имеет фиксированную цель и приводит к некоторому конечному результату. Имя работы должно выражать действие (например, «Изготовление детали», «Расчет допускаемых скоростей», «Формирование ведомости ЦДЛ № 3»).

Взаимодействие работ между собой и внешним миром описывается в виде стрелок. В IDEF0 различают 5 видов стрелок:

- вход (англ. input) - материал или информация, которые используются и преобразуются работой для получения результата (выхода). Вход отвечает на вопрос «Что подлежит обработке?». В качестве входа может быть как материальный объект (сырье, деталь, экзаменационный билет), так и не имеющий четких физических контуров (запрос к БД, вопрос преподавателя). Допускается, что работа может не иметь ни одной стрелки входа. Стрелки входа всегда рисуются входящими в левую грань работы;

- управление (англ. control) - управляющие, регламентирующие и нормативные данные, которыми руководствуется работа. Управление отвечает на вопрос «В соответствии с чем выполняется работа?». Управление влияет на работу, но не преобразуется ей, т. е. выступает в качестве ограничения. В качестве управления могут быть правила, стандарты, нормативы, расценки, устные указания. Стрелки управления рисуются входящими в верхнюю грань работы. Если при построении диаграммы возникает вопрос, как правильно нарисовать стрелку сверху или слева, то рекомендуется ее рисовать как вход (стрелка слева);

- выход (англ. output) - материал или информация, которые представляют результат выполнения работы. Выход отвечает на вопрос «Что является результатом работы?». В качестве выхода может быть как материальный объект (деталь, автомобиль, платежные документы, ведомость), так и нематериальный (выборка данных из БД, ответ на вопрос, устное указание). Стрелки выхода рисуются исходящими из правой грани работы;

- механизм (англ. mechanism) - ресурсы, которые выполняют работу. Механизм отвечает на вопрос «Кто выполняет работу или посредством чего?». В качестве механизма могут быть персонал предприятия, студент, станок, оборудование, программа. Стрелки механизма рисуются входящими в нижнюю грань работы;

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

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

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

1. Перед построением модели необходимо определиться, какая модель системы будет построена. Это подразумевает определение ее типа AS-IS, TO-BE или SHOULD-BE, а также определения позиции, с точки зрения которой строится модель. «Точку зрения» лучше всего представлять себе как место (позицию) человека или объекта, в которое надо встать, чтобы увидеть систему в действии. Например, при построении модели работы продуктового магазина можно среди возможных претендентов, с точки зрения которых рассматривается система, выбрать продавца, кассира, бухгалтера или директора. Обычно выбирается одна точка зрения, наиболее полно охватывающая все нюансы работы системы, и при необходимости для некоторых диаграмм декомпозиции строятся диаграммы FEO, отображающие альтернативную точку зрения.

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

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

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

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

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

6. У каждого блока должен быть как минимум один выход.

Работы без результата не имеют смысла и не должны моделироваться. Исключение составляют работы, отображаемые в модели AS-IS. Их наличие свидетельствует о неэффективности и несовершенстве технологических процессов. В модели TO-BE эти работы должны отсутствовать.

7. При построении диаграмм следует минимизировать число пересечений, петель и поворотов стрелок.

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

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

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

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

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

13. Каждый блок на диаграммах должен иметь свой номер. Для того чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Блок на диаграмме верхнего уровня обозначается 0, блоки на диаграммах второго уровня - цифрами от 1 до 9 (1, 2, …, 9), блоки на третьем уровне - двумя цифрами, первая из которых указывает на номер детализируемого блока с родительской диаграммы, а вторая номер блока по порядку на текущей диаграмме (11, 12, 25, 63) и т. д. Контекстная диаграмма имеет обозначение «А - 0», диаграмма декомпозиции первого уровня - «А0», диаграммы декомпозиции следующих уровней - состоят из буквы «А», за которой следует номер декомпозируемого блока (например, «А11», «А12», «А25», «А63»). В современных CASE-средствах механизмы нумерации работ поддерживается автоматически. CASE-средства обеспечивают также автоматическое построение диаграмм дерева узлов, которые содержат только иерархические связи. Вершиной такой диаграммы может быть любой узел (блок), и она может быть построена на любую глубину.

При построении функциональной модели системы альтернативой методологии SADT (IDEF0) является методология диаграмм потоков данных (Data Flow Diagrams, DFD). В отличие от IDEF0, предназначенной для проектирования систем вообще, DFD предназначена для проектирования информационных систем. Ориентированность этой методологии на проектирование автоматизированных систем делает ее удобным и более выгодным инструментом при построении функциональной модели TO-BE.

Как и в IDEF0 основу методологии DFD составляет графический язык описания процессов.

В настоящее время наиболее распространенной является нотация Гейна-Сарсона (Gane-Sarson).

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

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



2. Ориентированность предприятия на различные аспекты деятельности, миссию, технологии

Архитектура предприятия традиционно представляется в виде следующих слоев:

- корпоративные миссия и стратегия;

- бизнес-архитектура;

- системная архитектура (ИТ - архитектура).

Структура архитектуры предприятия представлена на рисунке 3.

Рисунок 3 - Архитектура предприятия

2.1 Миссия и стратегическое планирование

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

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

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

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

Процесс стратегического планирования в компании состоит из нескольких этапов:

- определение миссии и целей организации;

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

- выбор стратегии;

- реализация стратегии;

- оценка и контроль выполнения.

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

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

Формулировку миссии можно производить на основании вопросов:

1. Какой предпринимательской деятельностью занимается фирма?

2. Какова внешняя среда фирмы, определяющая ее рабочие принципы?

3. Какого типа рабочий климат внутри фирмы, культура организации?

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

Часто миссия отвечает на два основных вопроса: кто наши клиенты и какие потребности наших клиентов мы можем удовлетворить?

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

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

2.2 Бизнес-архитектура

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

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

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

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

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

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

1. Каков внешний контекст деятельности организации?

2. В чем состоят основные функции и добавочная стоимость, которая является итогом деятельности организации?

3. Какие сценарии развития бизнеса необходимо учитывать, и какова вероятность их реализации?

4. Какие необходимы информационные взаимосвязи и процессы обработки информации?

2.3 Системная структура предприятия

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

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

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

Прикладная архитектура включает в себя:

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

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

- средства и методы разработки и сопровождения приложений.

Архитектура данных включает в себя:

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

- системы управления базами данных или хранилищами данных;

- правила и средства санкционирования доступа к данным.

Техническая архитектура состоит из сетевой архитектуры и архитектуры платформ.

Сетевая архитектура включает в себя:

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

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

- аварийные планы по обеспечению бесперебойной работы сетей в условиях чрезвычайных обстоятельств.

Архитектура платформ включает в себя:

- аппаратные средства вычислительной техники - серверы, рабочие станции, накопители и другое компьютерное оборудование;

- операционные и управляющие системы, утилиты и офисные программные системы;

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

Далее в 3 разделе курсовой работы будет рассмотрена архитектура предприятия «АКонцепт» в модели AS-IS.



3. Организация работы предприятия «АКонцепт» в заданной архитектуре

Основной деятельностью компании «АКонцепт» является деятельность по созданию и продвижению сайтов, но помимо этого компания оказывает услуги по аудиту сайтов, консультации по бизнесу, а также выполняет мелкие работы по обслуживанию хостинга клиентов

Штат компании насчитывает 16 человек.

Цель компании - помогать вашему бизнесу развиваться в сфере интернет, используя самые современные технологии.

Миссия компании: «Вместе оказывать услуги профессионально».

Контекстная диаграмма предприятия представлена на рисунке 4.

Рисунок 4 - Контекстная диаграмма

После контекстной диаграммы необходимо представить диаграммы декомпозиции. Дальнейшая декомпозиция деятельности компании представлена на рисунке 5.

Рисунок 5 - Деятельность компании

На следующем рисунке представлена декомпозиция блока «Разработка стратегии и развитие бизнеса».



Рисунок 6 - Декомпозиция блока «Разработка стратегии и развитие бизнеса»

Далее следует декомпозиция блока «Продажи».

Рисунок 7 - Декомпозиция блока «Продажи»

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

Рисунок 8 - Планирование и осуществление проектных работ

На рисунке 9 представлена декомпозиция блока «Закупки и снабжение».



Рисунок 9 - Декомпозиция блока «Закупки и снабжение»

На следующем рисунке - декомпозиция последнего блока «Финансирование деятельности и отчеты».

Рисунок 10 - Декомпозиция блока «Финансирование деятельности и расчеты»



Более подробно декомпозируем блок «Реализация проекта» в блоке «Планирование и осуществление проектных работ».

Рисунок 11 - Декомпозиция блока «Реализация проекта»

Далее представлена дальнейшая декомпозиция блока блока «Реализация проекта, а именно бизнес-процесс «Анализ и разработка проекта» (рисунок 12) в нотации EPC.



Рисунок 12 - Анализ и разработка проекта



Рисунок 12 - Окончание

Чтобы рассмотреть другие нотации, рассмотрим на рисунке 13 бизнес-процесс «Формирование замечаний по проекту» в нотации BPMN бизнес-процесса «Завершение проекта и анализ результатов проекта».



Рисунок 13 - Формирование замечаний по проекту

На рисунке 14 представлен процесс «Обеспечение производства».



Рисунок 14 - Процесс «Обеспечение производства»

На рисунке 15 отображается процедура «Закрытие проекта».



Рисунок 15 - Закрытие проекта



Заключение

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

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

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

Также были представлены диаграммы в нотациях EPC, BPMN, а также в виде процесса и процедуры.

Размещено на Allbest.ru

...