Приведенный ранее подход описания схемы деятельности компании в виде нескольких уровней является адекватным с точки зрения того, что он раскрывает руководству механизм влияния решений в области ведения бизнеса на решения в области использования ИТ на предприятии.
Бизнес-архтпек?пура представляет собой совокупность функций и бизнес-процессов компании в привязке к отдельным организационноштатным элементам. Так распределяется ответственность за выполнение тех или иных функций и достижение целей каждого из процессов. Также в силу того, что в бизнес-архитектуру включается и стратегическая составляющая в виде целей и задач компании, связующим звеном между ней и организационной и процессной структурами являются ключевые показатели эффективности процессов KPI, достижение которых чаще всего становится целью отдельных руководителей, затем делегирующих ответственность и распределяющих цели каждого подразделения в зависимости от ожидаемого от них вклада в достижение поставленных перед руководством и перед компанией целей. В последнее время аналитики и архитекторы опираются на модель способностей компании. Эту модель активно поддерживает и развивает IBM Institute for Business Value. При анализе и проектировании бизнес-архитектуры исследуется модель создания ценности, бизнес-модель компании, сервисы компании, система используемых знаний и пр.
Построение бизнес-архитектуры при управлении информационными системами критически важно, так как именно на этом уровне формируются бизнес-цели, влияющие на общее состояние ИТ, трансформирующееся в ИТ-цели и задачи. Если проводить моделирование бизнес-слоя архитектуры предприятия (модель бизнес-процессов) с учетом референтных моделей, то бизнес-архитектуру можно рассматривать и с точки зрения сервисного подхода. В таком случае бизнес-подразделения производят определенные услуги для внешних и внутренних заказчиков в целях исполнения ключевых для компании бизнес-процессов. В то же время ИТ-подразделения с помощью своих активов (инфраструктура, программные решения, ИТ-персонал) предоставляют сервисы, поддерживающие бизиес-процессы компании. При этом часто считается, что в случае бизнес-подразделений основной акцент делается на ценности сервисов и их роли в достижении бизнес-целей, а для ИТ наиболее важны достижение ИТ-целей, формализованность и качество исполнения процессов.
Именно в силу тесной связи бизнес-процессов и существующих в них информационных потоков после архитектуры бизнес-процессов следующим по «иерархии» уровнем является архитектура данных (информационная архитектура), описывающая информационную модель со всеми базами и хранилищами данных, а также потоков информации (как внутри организации, так и при взаимодействии с внешними сторонами).
Реферат бизнес план производства
... Бизнес-план можно составлять на несколько лет вперед, с его корректировкой и пересмотром по мере необходимости. Целью ... производства в сложившихся экономических условиях. Законодательство не закрепляет обязательность разработки бизнес-плана. Зарубежный опыт и пока еще небольшой опыт отечественных предприятий показывают, что составлять бизнес-планы заставляет сама жизнь. Бизнес-план ... с тем следует ...
Именно архитектура данных создает необходимые условия для внедрения систем классов BI и MDM (система управления мастер-данными).
На практике построение архитектуры данных чаще всего проводится в рамках четырех активностей: описание архитектуры данных, определение модели управления данными, управление требованиями по безопасности данных, управление качеством данных. На практике все активности, связанные с информационной моделью, призваны привести к наличию единого набора данных, которые могут использоваться любыми существующими и будущими приложениями.
Прикладная архитектура представляет собой область разработки, эксплуатации и поддержки программных решений (приложений), включая интерфейсы взаимодействия между ними (интеграцию).
Именно поэтому некоторые организации (например консалтинговая компания Accenture) выделяет отдельно архитектуру интеграции как описание программноаппаратного решения по обеспечению взаимодействия приложений.
Говоря о прикладной архитектуре, невозможно обойти стороной базовые принципы формирования портфеля приложений на предприятии. Иногда в компании выделяется должность главного ИТ/системного архитектора, иногда ее функции распределяются между несколькими сотрудниками. Тем не менее предприятию важно в каждый момент времени иметь четкое представление о текущем ландшафте приложений (т.е. списку/схеме систем с описанием взаимосвязей между ними).
Причин этому несколько. Во-первых, со стратегической точки зрения наличие текущей карты систем (независимо от ее формата) позволит увидеть несоответствия с целевым состоянием и принять необходимые меры для эффективной поддержки автоматизации бизнес-процессов. С другой стороны, это позволит избежать возникновения проблем, связанных с унаследованными (legacy) системами, более не соответствующими текущим потребностям бизнеса, но по-прежнему находящимися в эксплуатации.
Перейдем от рассмотрения программных решений к архитектуре их интеграции. Существуют два основных метода установления связи для передачи данных: выполняется либо интеграция непосредственно между приложениями («точка-точка»), либо применяется сервисная шина. Первый способ предпочтителен в случае больших объемов передаваемой информации или технической сложности интеграции приложений через шину вследствие накладываемых ею ограничений (например, по стандартам передачи данных).
В свою очередь использование сервисной шины позволяет оперативно передавать один и тот же массив данных нескольким информационным системам и в дальнейшем присоединять и другие внедряющиеся системы по стандартным протоколам. Данные моменты отражаются при моделировании архитектуры предприятия в методологиях TOGAF/Gartner. Это позволяет определить, какое место займет новая внедряемая система в общем ландшафте систем, а также какие системы (и как) должны в первую очередь поддерживаться с точки зрения выделения инфраструктурных ресурсов. На этом шаге возможно уже переходить к их рассмотрению в рамках технической архитектуры («https:// «, 19).
Создание отчета как объекта базы данных. Экспертные и обучающиеся системы
... закрыть отчет. Экспертные и обучающиеся системы Экспертные системы являются одним из основных приложений ... (меню Файл). При разработке макетов отчета руководствуйтесь следующей формулой: ширина отчета + левое поле ... отчета. Используется для вывода данных, таких как текст заголовка отчета, ... экспертными: Модельные информационные системы предоставляют пользователю модели (математические, статистические, ...
Наконец, уровень технической архитектуры отвечает за повышение эффективности использования вычислительных ресурсов и определяет инфраструктурные ресурсы и сервисы, необходимые для корректной работы приложений и передачи потоков данных между ними. При описании технической архитектуры рассматриваются:
-
- вычислительная инфраструктура:
- — базовые инфраструктурные сервисы,
- — серверное и пользовательское оборудование и СХД,
- — серверные площадки и ЦОД,
- — системное ПО;
- сетевая инфраструктура:
- — инфраструктура ЛВС,
- — корпоративные сети передачи данных (КСПД),
- — телефония, ВКС, подключение к сети Интернет;
- инженерная инфраструктура.
Разумеется, данные компоненты могут быть сгруппированы в другом виде, их список может быть расширен/сокращен. К тому же управление элементами технической архитектуры возможно организовать через выделение определенных классов (например, по доступности, производительности серверных систем, по обслуживанию каналов связи).
Таким образом, уже в ходе работы с каждым из уровней архитектуры предприятия были сделаны важные выводы о его структуре, о приоритетах компании в области развития бизнеса и ИТ, которые в дальнейшем могут быть использованы в ходе любых проектов внедрения. Затем в качестве итогового результата можно «связать» эти уровни воедино для формирования более целостного представления.
Важно упомянуть о существовании так называемых референтных моделей, объединяющих лучшие практики, знания о которых собирались в течение многих лет. Например, в рамках инициативы международной организации была разработана модель телекоммуникационной индустрии еТОМ, описывающая техническую, технологическую и организационную составляющие деятельности любого оператора связи/поставщика телекоммуникационных услуг (рис. 6.17).
Можно констатировать, что модель еТОМ объединяет ключевые процессы, существующие в сфере предоставления услуг внутри телекоммуникационной отрасли. Модель еТОМ может быть взята за основу при создании модели работы мобильного оператора, компании с терминалами оплаты услуг и т.н.
Еще один известный пример референтной модели — модель SCOR. С помощью модели SCOR описывают цепочку грузопоставок за счет использования единой терминологии и единой системы взаимосвязей. Референтная модель SCOR облегчает анализ, сравнение и диагностику процессов в логистике. Развитие предприятия на основе референтной модели становится простым, наглядным и удобным, причем результат рассматривается как гораздо более предсказуемый.
Однако все ранее рассмотренные примеры нотаций и моделей используют «трансформационный подход» (вход-процесс-выход) и не содержат средств оценки оптимальности бизнес-процесса. Возвращаясь к терминам сервисного подхода, стоит сказать, что они не описывают отношение запроса на услугу (заказчика) и результата исполнения услуги (поставщика услуг).
25 стр., 12332 словРазработка бизнес-архитектуры предприятия на основе информационной ...
... бизнес-модель предприятия, документы, используемые в процессе разработки и реализации продуктов. Если смотреть более подробно, бизнес-архитектура включает в себя планируемый список продуктов и/или услуг, ... компонентов, связанных с инфраструктурой предприятия, таких как методологическая и инструментальная база для разработки моделей конкретных бизнес-процессов. Данные работы требуют достаточно много ...
Эта проблема была впервые описана сообществом исследователей сети CIAO! и предложенное ими решение уже распространено в Европе. Итак, CIAO!, разработали методологию дизайна и инженерии для организаций DEMO (Design & Engineering Methodology for Organizations).
В ее основе — идея определения шаблонов взаимодействия инициатора и исполнителя услуги на двух стадиях: получения заказа и получения результата.
Для построения DEMO разработчики предлагают опираться на процессные модели BPMN, дополняя их диаграммами бизнес-транзакций и процессной структуры (определяя результаты производства продуктов/ услуг).
Применение подобного подхода в крупной организации позволило, например, определить отсутствие необходимых активностей по координации («Обещание» и «Согласование») практически в половине случаев, а активностей «Запрос» и «Статус» — в 25% случаев. Это в свою очередь являлось одной из причин неудовлетворенности предоставляемыми услугами и недостаточной эффективности сервисной деятельности в компании, ведь без определенных действий по явному запросу на услугу, явной приемки результата, постоянной коммуникации общий результат выполнения бизнес-процесса и предоставления услуги не будет соответствовать ожидаемому.
На примере DEMO наглядно показаны современные тенденции интеграции нескольких подходов, методологий, техник (возможно, существующих и применяющихся уже десятилетиями).
Часто это позволяет создать более полную картину, охватывающую несколько особо важных аспектов. Методология DEMO подробнее рассмотрена в подпараграфе 6.5.4.
В итоге построенные модели процессов и процессный подход в управлении в целом позволяют существенно увеличить конкурентоспособность проекта/предприятия, повысить его гибкость в отношении изменений конъюнктуры рынка, радикально усовершенствовать качество продуктов и услуг.
- Key Performance Indicators (ключевые показатели эффективности).
- Источник: .
- вычислительная инфраструктура:
