Бизнес архитектура предприятия это – 3. Бизнес – архитектура предприятия

Содержание

3. Бизнес – архитектура предприятия

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

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

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

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

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

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

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

Построение бизнес — архитектуры начинается с описания контекста бизнес — архитектуры (рисунок 1.8.).

Общее видение бизнес — архитектуры предприятия включает анализ основных функций, цепочек создания добавленной стоимости (ValueLandscapeAnalysis), модели бизнес – сценариев (BusinessScenarioModels), анализ информационных связей и процессов (InformationValueChainAnalysis).

Рисунок 1.8. Контекст бизнес архитектуры

Основу архитектуры предприятия составляет: анализ бизнес событий (BusinessEventAnalysis), декомпозиция функций и процессов (Function/ProcessDecomposition), модель расположения (LocationModel), модель интеграции (IntegrationModel).

Бизнес — архитектура представляется в виде набора бизнес моделей. Бизнес модели – это «набор событий, связанных с бизнесом, в который вовлечены различные функции бизнеса, организационные единицы и активы предприятия».

В настоящее время существуют различные методики описания бизнес — архитектуры предприятия. Например, в работах Джона Захмана выделяются следующие типы бизнес моделей:

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

  • Динамические модели бизнес-процессов, включающие детализированное описание функционирования компании.

  • Организационная структура компании.

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

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

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

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

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

  • выделить ключевые бизнес-процессы;

  • выделить дублирующие бизнес-процессы и точки их пересечения.

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

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

Модель интеграцииопределяет связь бизнес-процессов и бизнес — событий.

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

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

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

4. ИТ — архитектура предприятия

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

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

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

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

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

  • Enterprise Information Architecture (EIA) – информационная архитектура.

  • Enterprise Solution Architecture (ESA) – архитектура прикладных решений.

  • Enterprise Technical Architecture (ETA) – техническая архитектура.

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

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

studfile.net

А Вы знаете, что такое проектирование бизнес-архитектуры компании? : Энциклопедия результативного маркетинга

И нужна ли она Вам?

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

Что представляет из себя бизнес-архитектура?

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

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

В чём же выход? Давайте представим бизнес в форме здания. Для строительства здания архитектору необходим его «чертёж». То же самое происходит и с компанией. Создание такого «чертежа» компании, в свою очередь, называется «бизнес-моделированием», а сам «чертёж» — «бизнес-архитектурой».

Проектирование бизнес-архитектуры компании

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

Бизнес — очень сложная система, поэтому его тоже необходимо проектировать.

Бизнес-моделирование — это процесс создания бизнес-архитектуры компании.

Бизнес-архитектура — это модель бизнеса, содержащая следующие элементы и их связи:

  1. Цели бизнеса.

  2. Бизнес-процессы.

  3. Организационную структуру.

  4. Информационные системы.

  5. Ресурсы и данные.

Зачем нужно бизнес-моделирование?

Единственная цель бизнес-моделирования — создание эффективного бизнеса. При этом бизнес-моделирование решает следующие задачи:

  1. Дать детальное представление об устройстве компании всем заинтересованным лицам.

  2. Обеспечить создание оптимальной бизнес-архитектуры.

  3. Сформировать требования к информационным системам.

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

Справляться с решением данных задач помогает система бизнес-моделирования Business Studio, разработанная ГК «Современные технологии управления», которая, в свою очередь, является партнёром Zolle.

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


Более подробно о возможностях BS я расскажу Вам в следующей статье.

Если у Вас остались вопросы — задавайте их в комментариях.


Валерия Репина,бизнес-аналитик

Статьи в тему



blog.zolle.ru

Бизнес-архитектура — Business architecture — qwertyu.wiki

Аспекты бизнеса Обозначается архитектура бизнеса

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

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

На практике определение TOGAF наиболее часто используется в топ 2000 организаций (например, в Wells Fargo). Проблема с этим определением в том, что почти все становится бизнес-архитектуры, он не ограничивает сферу достаточно (по мнению экспертов Bizbok и OMG). Проблема с определением OMG является то, что он не определяет бизнес-архитектуру, но относится к предпринимательской копирку. Проблема с определением Dragon1 для некоторых, которые вы должны знать, что бизнес-концепция, прежде чем понять, что бизнес-архитектура. Независимо от определения, многие бизнес-проекты архитектура обеспечивают отображение возможности бизнес-выровнены и позволяет стратегию организации. И это измеримые выгоды в любой организации работы с бизнес-архитектуры.

Люди , которые развивают и поддерживают бизнес — архитектуры известны как бизнес — архитектор .

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

обзор

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

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

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

История архитектуры бизнеса

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

Концепция бизнес — архитектуры развивалась на протяжении многих лет. Он был введен в 1980 — х годах , как архитектурные домены и как деятельность бизнес — модели. В 2000 — е годы исследования и концепции развития архитектуры бизнеса ускорился. К концу 2000 — х годов были опубликованы первые учебники по бизнес — архитектуры, отдельные рамки для бизнес — архитектуры были разработаны отдельные виды и модели бизнес — архитектуры были дополнительно на стадии строительства, бизнес — архитектор как профессия развивается, и все большее число бизнес добавил архитектуру бизнеса в их повестку дня.

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

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

Различные виды организации

Для того , чтобы разработать комплексную картину работы предприятия, как правило , разработаны многие различные виды организации. Каждый «вид» , как правило , диаграмма , которая иллюстрирует способ понимания предприятия путем выделения конкретной информации о нем. Основные виды деятельности предприятия , которые могут быть предоставлены по бизнес — архитектура адрес несколько аспектов деятельности предприятия; они обобщаются Object Management Group (2012) следующим образом :

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

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

Бизнес стратегия

В 2006 статье «Бизнес — архитектура: новая парадигма связать бизнес — стратегию ИКТ,» Versteeg и Bouwman объяснил связь между бизнес — стратегии и бизнес — архитектуры. Они написали:

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

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

Подходы и рамки для бизнес-архитектуры

Захмана

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

Management Object Group

Моделирование стандартов Object Management Group (OMG), в том числе Unified Modeling Language (UML), Model Driven Architecture (MDA), Business Motivation Model (ВММ), семантике деловой лексики и правил (SBVR) и моделирования бизнес — процессов нотация ( BPMN), и решение модели и нотация (ДМН) позволяют мощный визуальный дизайн, оформление и сопровождение программного обеспечения и других процессов, в том числе ИТ — систем моделирования и управления бизнес — процессами . В настоящее время OMG работает на Value Delivery Modeling Language (VDML), стандартный язык моделирования для анализа и проектирования работы предприятия с особым упором на создании и обмен стоимости

Бизнес Архитектура Guild

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

Основанная в конце 2010 года Гильдия открыл членство осенью 2011 года на основе первоначального выпуска Руководство по бизнес-архитектуры Своду знаний (R) (BIZBOK (R) Руководство). BIZBOK (R), в настоящее время в версии 6.0, является «практическим руководством для бизнес-практиков и лиц архитектуры, которые хотели бы использовать бизнес-архитектуры для решения бизнес-задач. Это практическое руководство поставляется в виде передового опыта, почерпнутые из многочисленных компаний и бизнес-архитектуры лидеры. «.

Ассоциация Бизнес-Архитектура

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

Открытая группа

Архитектура Framework Open Group (TOGAF) из The Open Group это стандарты усилий на уровне общин для описания методов и инструментов , используемых архитектуры. Она разрабатывается и постоянно совершенствуется с помощью Open Group, консорциум заинтересованных лиц и компаний , занимающихся информационными технологиями.

По TOGAF, Бизнес — Архитектура «определяет стратегию бизнеса, управления, организации и ключевых бизнес — процессов». TOGAF относится к бизнес — архитектуре в качестве одного из четырех архитектурных областей, которые представляют собой подмножество общей архитектуры предприятия с тремя других архитектурами доменов архитектуры приложений, архитектуры данных и технологией архитектура. Ключевой элемент TOGAF, Метод разработки архитектуры, определяет развитие бизнес — архитектура в качестве необходимого условия для развития других областей архитектуры и дает рекомендацию в отношении шагов развития и общих артефакты.

Framework ASATE Group Business Capability

ASATE Group Business Capability Framework зависит от бизнес-возможностей и восемь типов строительных блоков, которые делают их (процессы, функции, организационные единицы, ноу-хау активов, информационные активы, технологические активы, бренды и депозиты природных ресурсов) для моделирования бизнес архитектура. Эта структура была разработана с пятью критериями в виду: (1) должны быть приведены в соответствие со стандартным определением архитектуры ANSI / IEEE 1471-2000; (2) должны разделять точку привязки с бизнес-стратегией, а именно возможности; (3) должны опираться на общие бизнес-терминов и их определений; (4) должна включать все виды строительного блока, необходимые для моделирования полной бизнес-архитектуры; и (5) не должны быть обременены типов ненужных строительных блоков.

эталонные модели промышленности

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

  • Framework бизнес — процессов (етом) , опубликованной TM Forum , описывает полный спектр бизнес — процессов , необходимых поставщиком услуг в сфере телекоммуникаций, а также определяет ключевые элементы и как они взаимодействуют.
  • Классификация процесс Framework (PCF), опубликованное APQC, создает общий язык для организаций, для общения и определяют рабочие процессы комплексно и без излишеств. Организации используют его для поддержки сравнительного анализа, управления контентом, а также выполнять другие важные мероприятия по управлению производительностью.
  • Цепочки поставок операции Reference (СКОРО) была запатентованная эталонным процесс модели, опубликованная Supply-Chain Council. Совет Supply-Chain слилась с APICS в 2014 году.
  • OpenReference является Open , редактируемые ссылки на бизнес — терминов, строительство в сторону общего языка для описания эффективности бизнеса, процессов, методов и условий. Ссылка поддерживается добровольцами инициативы OpenReference .

Смотрите также

Рекомендации

дальнейшее чтение

  • Велэн, J .; Meaden, G. (2012). Бизнес Архитектура: Практическое руководство . Ashgate. ISBN  978-1-4094-3859-5 .
  • Росс, Жанна ; Вейл, Питер ; Робертсон, Дэвид С. (2006). Архитектура предприятия Как Стратегия: Создание Фонда для бизнеса выполнения . Harvard Business Review Press. ISBN  978-1591398394 .
  • Пулен, Майкл (2013). Архитекторы знают , что менеджеры не: Бизнес — архитектура для динамического рынка . BuTechCon. ISBN  978-0-9575199-0-9 .
  • Ulrich, Уильям ; McWhorter, Нил (2010). Бизнес Архитектура: Искусство и практика трансформации бизнеса . Меган-Kiffer Press. ISBN  0-929652-15-0 .
  • Versteeg Г. ; Боуман, H. (2006). «Бизнес — архитектура: новая парадигма связать бизнес — стратегии к ИКТ». Информационные системы Frontiers . 8 (2): 91-102. DOI : 10.1007 / s10796-006-7973-г .
  • Виттл, Ральф; Мирик, Conrad (2004). Enterprise Business Architecture: Формальная связь между стратегией и результатами . CRC Press. ISBN  978-0849327889 .
  • Клементе Minonne (2016), Бизнес — анализ — KONZEPTE, Methoden унд Instrumente цур Optimierung дер Бизнес-архитектура (на немецком языке ) (1. (немецкая) под ред.), Шеффер-Poeschel, Штутгарт, ISBN  978-3-7910-3308-2

внешняя ссылка

СМИ , связанные с бизнес — архитектуры на Викискладе

ru.qwertyu.wiki

В чем заключается роль бизнес-архитектора в компании / Habr

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

Обсуждение за круглым столом, модератором которого была Дэйна Гарднер, главный аналитик Interarbor Solutions, началось с утверждения:

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

Участники круглого стола, Жанна Росс, директор и ведущий исследователь MIT Center for Information Systems Research, Дейв Хорнфорд, главный специалист по бизнес-архитектуре Integritas Solutions и председатель The Open Group Architecture Forum, и Лен Фескенс, вице-президент направления по развитию навыков и способностей The Open Group, помогли сформулировать следующее:

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

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

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

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

Росс также отметила:

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

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

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

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

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

В продолжение дискуссии о проблеме перспективной ценности бизнес-архитекторов Фескенс заявил:

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

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

Росс предостерегла, что потенциальную ценность бизнеса далеко не всегда можно извлечь сразу же — обычно это происходит в перспективе:

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

Гарднер подвела черту под обсуждением следующим образом:

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

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

habr.com

Бизнес-урок 6. Архитектура бизнес-процессов |

В предыдущей статье мы рассмотрели порядок разработки организационной концепции и подробно обсудили три ее элемента: (1) состав основных процессов верхнего уровня, (2) описание этих процессов и (3) карту процессов. Чтобы завершить обсуждение этой темы, рассмотрим следующие два элемента организационной концепции: (4) схема центров ответственности, (5) концептуальное описание центров ответственности. Но прежде необходимо дополнить состав наших бизнес-процессов. Дело в том, что мы рассмотрели только основные процессы компании, в то время как помимо них имеются обеспечивающие процессы, процессы развития и процессы управления.

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

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

Процессы управления

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

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

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

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

С методикой и технологией построения стратегического управления можно ознакомиться в электронном учебном курсе “Управление стратегией с помощью сбалансированной системы показателей”. Это пошаговое практическое руководство по созданию системы стратегического контроллинга.

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

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

Процессы развития

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

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

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

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

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

Концепция управления проектами развития содержится в материалах вебинара “Управление проектами. Суть дела”. Используйте эти материалы для создания организационной концепции вашей компании.

Центры ответственности

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

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

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

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

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

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

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

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

blog.iteam.ru

Бизнес-архитектура предприятия.

⇐ ПредыдущаяСтр 2 из 3Следующая ⇒

Элементы архитектуры предприятия

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

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

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

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

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

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

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

Бизнес-архитектура
Требования к информации Функциональные требования Операционные требования
↑↓ ↑↓ ↑↓
Архитектура информации ← → Архитектура приложений ← → Технологическая архитектура
ИТ
             

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

Основа бизнес-архитектуры:

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

· Архитектура БП-определяет основные функциональные возможности организации.

· показатели эффективности.

· модели процессов (потоков работ)

· функциональные модели

· модели данных ресурсов

· временные модели типа диаграммы ганта

· модели причинно-следственных связей

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

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

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

· Декомпозиция функций(процессов)

· Анализ бизнес-событий

· Моделирование местоположений выполняемых функций/процессов

· Модель интеграции функций и процессов

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

Декомпозиция функций/процессов должна

· Задавать границы анализа/рассмотрения наиболее важных функций бизнеса

· Идентифицировать основные процессы обеспечивающие выполнение функций организации

· Идентифицировать меж функциональные процессы

· Идентифицировать пересечения и излишние функции /процессы.

 

Выбор аппаратно программной платформы.

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

· отношение стоимость/производительность

· надежность и отказоустойчивость

· масштабируемость

· совместимость и мобильность программного обеспечения.

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

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

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

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

Совместимость и мобильность программного обеспечения.

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

 

Концепция MRP

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

Основными целями автоматизированных MRP-систем являются:

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

· поддержка уровней запасов не выше запланированных;

· планирование производственных операций, расписаний доставки, закупочных операций.

Шаги планирования

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

· Заказы (Orders) упорядочиваются, например, по приоритетам или по срокам отгрузки.

· Формируется объемный план-график производства (Master Schedule). Обычно он создается по группам продукции и может быть использован для планирования загрузки производственных мощностей.

· Для каждого изделия, попавшего в план-график производства, состав изделия «детализируется» до уровня заготовок, полуфабрикатов, узлов и комплектующих изделий.

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

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

Выход: План заказов, отчет изменений в плане заказов,отчет об «узких местах» плана планирования, отчёт о прогнозах

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

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

 

Стандарт MRP II.

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

Вход: План выписки продукции, технологический маршрут

Выход: план потребности в производственных мощностях.

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

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

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

Задачи решаемые MRP II:

· планирование продаж и производства

· планирование материальных потребностей

· спецификации конечных продуктов

· планирование производственных мощностей CRP

· финансовое планирование

· управление спросом

· планирование и управление инструментальными средствами

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

MRPII – центральная часть любой КИС на производственных предприятиях.

Преимущества MRP II

· улучшение обслуживания заказчиков за счет своевременного исполнения поставок;

· сокращение цикла производства и цикла выполнения заказа, следовательно, более гибкая реакция на спрос;

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

· значительное сокращение запасов, что позволяет более экономно использовать складские помещения и сокращает расходы на хранение;

· сбалансированность запасов – уменьшение дефицита и устаревших запасов;

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

 

 

Концепции ERP.

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

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

ERP -системы ориентированы на работу с сетьюудаленных производственных и непроизводственных объектов (включают еще и механизм планирования потребностей при распределенных запасах (Distribution Requirements Planning).

Основа ERP-систем — принцип создания единого хранилища (репозитория) данных для всей, корпоративной информации.

ERP Система – набор компьютерных программ, реализующих методологию MRP II, дополненных средствами оптимизации управления производственными и сбытовыми подразделениями размещенными в разных странах.

Современная ИСУП соответствует концепции ERP, помимо блока реализуемого требованиям стандарта MRP, должна включать подсистемы:

· Управления цепочками поставок

· Конфигурации системы

· Интеллектуального анализа бизнеса

· Электронной коммерции

· И т.д.

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

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

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

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

Достоинства

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

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

Недостатки

· Небольшие компании не могут позволить себе инвестировать достаточно денег в ERP и адекватно обучить всех сотрудников.

· Внедрение является достаточно дорогим.

· Система может страдать от проблемы «слабого звена» — эффективность всей системы может быть нарушена одним департаментом или партнёром.

· Проблема совместимости с прежними системами.

 

 

Функциональные подсистемы ERP

· Планирование продаж и производства. Результатом действия блока является разработка плана производства основных видов продукции.

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

· Укрупненное планирование мощностей. Используется для конкретизации планов производства и определения степени их выполнимости.

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

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

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

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

· Маршрутизация / рабочие центры. С помощью этого блока конкретизируются как производственные мощности различного уровня, так и маршруты, в соответствии с которыми выпускаются изделия.

· Проверка и корректировка цеховых планов по мощностям.

· Управление закупками, запасами, продажами.

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

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

· Управление проектами/программами.

· Управление персоналом.

 

Концепции ERP II.

В ноябре 2000 года на ежегодном ИТ-симпозиуме в Каннах компания Gartner объявила о разработке и начале продвижения на рынок новой концепции построения комплексных систем управления ресурсами предприятий ERP II. В данной концепции сделана попытка объединения концепций ERP, CRM (Customer Relationship Management, концепция управления взаимоотношениями с клиентами), SCM (Supply Chain Management, концепция управления цепочками поставок) и электронной коммерции в единую систему управления всеми (внутренними и внешними) ресурсами предприятия.

Помимо расширения и углубления функциональности и использования возможностей Интернета еще одной характерной чертой новой концепции ERP II является тенденция к специализации систем на отраслевых/промышленных сегментах. Прогнозируется снижение значимости универсальности решений для достижения конкурентных преимуществ на рынке.

Отличия от ERP:

· Изменена роль ERP-системы в деятельности предприятия.

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

· Расширена область применения ERP-систем.

o Если раньше основными потребителями ERP-систем были производственные и дистрибьюторские предприятия, то пользователями ERP II-систем должны стать предприятия всех секторов и сегментов рынка.

· Расширен функционал ERP-систем.

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

· Меняется характер процессов, протекающих в недрах ERP-системы.

o Внутренние и строго конфиденциальные процессы становятся внешними и открытыми. Все тайны корпоративной информации должны быть раскрыты.

· Существенным образом меняется архитектура ERP-систем.

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

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

· Новые типы приложений, отвечающие за связь предприятия с внешним миром, такие как:

o программы для управления взаимоотношениями предприятия с ее клиентами/заказчиками (CRM — Customer Relationship Management),

o системы управления цепочками поставок (SCM — Supply Chain Management),

o системы электронного бизнеса/электронной коммерции (набор автоматизированных бизнес-процессов, осуществляемых с использованием Интернет-технологий).

· Расширение внутренней структуры — за счёт

o HRM (Human Resources Management) и

o KM (Knowledge Management) модулей.

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

KM-системы предназначены для управления корпоративными знаниями.Исторически эти системы создавались для накопления корпоративных знаний и использовались для внутреннего потребления. С развитием CRM-систем оказалось, что KM-системы идеально подходят для создания автоматизированных справочных бюро (Help Desks) и решения задач интеллектуального анализа информации по клиентам (выявление потребительских пристрастий, профилирование и пр.)

ERP   ERP II
Оптимизация процессов предприятия Роль Участие в цепочке, обеспечивающей увеличение стоимости, создание условий для совместной коммерции
Производство и дистрибуция Область деятельности Все сегменты и секторы
Производство, торговлю (дистрибуция) и финансовые процессы Функции Межотраслевые и отраслевые секторы, специфичные производственные процессы
Внутренние, спрятанные Тип процессов Связанные на внешнем уровне
С элементами, позволяющими работать с Web, закрытая, монолитная. Архитектура Интернет-ориентированная, открытая, компонентная
Генерируемые и используемые внутри предприятия Данные Предназначены как для внутреннего, так и для внешнего использования

 

 

 

Концепции Workflow.

WorkFlow-системы предназначены для комплексной автоматизации управления бизнес-процессами и являются развитием систем маршрутизации документов.

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

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

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

Согласно модели workflow-система должна включать следующие службы:

· систему визуального описания последовательности этапов (аctivities) и инфраструктуру для хранения шаблонов бизнес-процессов;

· сервис, обеспечивающий запуск и исполнение бизнес процессов;

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

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

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

Концепция workflow предполагает наличие центра управления.




infopedia.su

Бизнес-архитектура: моделирование полезности (value) и справляемости с (capabilities): ailev — LiveJournal

Бизнес-архитектура (business architecture) это совсем не то же самое, что «просто часть архитектуры предприятия» (enterprise architecture) с тамошней «архитектурой деятельности» (как правильно было бы переводить в большинстве околоайтишных случаев слово business, в буквальном его переводе «бизнес» явно имеющее предпринимательский смысл). Я бы честно переводил по-разному «архитектуру деятельности» в разных околоайтишных подходах типа Архимейт и «родную» business architecture с её лозунгом «начинайте с бизнес-модели». Традиционная (не-айтишная) бизнес-архитектура — это «про всё важное» (помним про определение архитектуры!) для бизнеса, т.е.:
— предпринимательскую стратегию
— формулирование/документирование этой стратегии
— переход к выполнению сформулированной стратегии.

Бизнес-архитектура является традиционной вотчиной экспертов из McKinsey & Co, Bain & Co, Booz & Co, BCG, Palladium и прочих всеми ругаемых «консультантов не по делу». Именно это преподаётся в разных университетах в курсах MBA. Ключевые слова тут — «кому это нужно» (полезность, value), «справляемся ли мы с» (capability, над переводом думать и думать), «мы банда» (сообщество, кластер, фирма, рабочая группа) и т.д.. Обратите внимание, как этот «предпринимательский» разговор (начинающийся с вопроса о том, кому всё это нужно и зачем мы всё это делаем) отличается от «работ/процессов», «акторов», «функций» и прочего привычного менеджерского и инженерного разговора, очень важного для организации эффективного производства (которое крайне важно, когда вы уже знаете, что производить, и вам нужно сделать подешевле и побыстрее). Кроме «побыстрее» и «подешевле», или даже «чтобы результат был качественный» (инженерный взгляд на вещи), бизнесменам нужно ответить на вопрос «зачем это вообще делать» (не технологическая причинно-следственная цепочка, а ценностная — нужно ли кому-нибудь затеваемая деятельность).

На сегодня есть:
— гильдия бизнес-архитекторов — http://www.businessarchitectureguild.org/ (главный продукт — Business Architecture Body of Knowledge, BIZBOK™, к концу года выйдет уже версия 3.0). Это новое объединение, организации всего пара лет, они делают акцент на то, что это «знание архитекторов от сохи».
— ассоциация бизнес-архитекторов — http://www.businessarchitectsassociation.org/ (главный продукт — сертификация бизнес-архитекторов), это смычка университетов и консалтеров. Обратим внимание, что гильдия бизнес-архитекторов придерживается других взглядов на предмет, чем ассоциация (отчетливо это проявляется в репликах William Ulrich треда http://www.linkedin.com/groups/When-Stars-Align-Business-Architecture-4379346.S.130420677).
— SIG в OMG — http://bawg.omg.org/ (стандарт VDML — это как раз их рук дело, презентации http://bawg.omg.org/12-06-01.pdf, текст последней версии — http://neffics.eu/wp-content/uploads/2012/06/12-05-02.pdf).
— дискуссионная группа в LinkedIn — http://www.linkedin.com/groups/Business-Architecture-Perspectives-Transforming-Business-4379346
— разные вебсайты типа http://www.bainstitute.org/ (утверждают, что там комьюнити более 40тыс. членов, родственные сайты BPMinstitute.org и SOAinstitute.org — ну, вы поняли).
— школы типа http://paularthurbodine.com/the-chicago-school-of-business-architecture/
— и много чего другого, ссылки наверху даже не надводная часть айсберга, это махонький кусочек.

Архитектура предприятия (включая тамошнюю архитектуру деятельности) — это то, чем сегодня занимаются не столько стратеги, сколько выходцы из айтишников, включая «бизнес-аналитиков» (которые опять же, про «деятельность» как тип для повторяющихся в чём-то дел, но не про «бизнес» в предпринимательском смысле этого слова), тоже вырастающих из программистов. Это часть enterprise engineering, которая в свою очередь часть systems engineering в части систем предприятий. Распознать, с какой именно архитектурной школой мы имеем дело легко: айтишники мыслят прежде всего «процессно» (в крайнем случае — сервисно), что позволяет относительно легко объяснять, как используется софт. Даже «антипроцессники» с трудом понимают, о чем вообще эти «бизнес»-архитекторы говорят (см., например, недоумения Max Pucher по поводу VDML — http://www.linkedin.com/groups/VDML-ACM-DCM-2452802.S.88269024, он видит в capabilities и value chains главным образом motivation model, а затем быстро переходит к GRL-для-предприятий, собственно как и реализовано в «стратегии-для-айтишников» OMG BMM). Обратный ход от «стратегов» к айтишникам тоже делается — вот, например, попытка: http://www.valuenetworksandcollaboration.com/advanced/processworkflowvna.html (опять же, обратите внимание упор на intangibles — это явно не artifact-based!).

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

В «большой системной инженерии» (читай: военной системной инженерии) этот тренд на «бизнес-архитектуру» проявляется в резком сдвиге от обсуждения системы-как-сервисной к обсуждению всяческих capabilities в systems of systems engineering. Никакого «бизнеса» у военных, но вот самый верхний «стратегический» уровень заказа работ системным инженерам (acquisition) — это заказ capabilities, а не systems или services. Заказывается поддержка возможности что-то делать, а не системы или сервисы этих систем. Это тот же тренд, что и в организациях, от которых требуют «конкурентоспособности», а не «поддержки сервиса по выигрышу конкуренции».

ArchiMate 2.0 (http://pubs.opengroup.org/architecture/archimate2-doc/) является неплохой попыткой гармонизации мира «бизнесОв» и «операционистов-процессников», но и там айтишники с их «сквозными процессами» на диаграммах являются главными, а все эти value и «стратегические» дополнения версии 2.0 только аннотируют основное процессное блюдо, а не являются полноценными главными объектами для архитектурной работы. То же можно сказать про все остальные enterprise architecture frameworks: их делали айтишники, менеджерам с ними плохо, они не про «бизнес», а больше про «операции».

Так что стоит задача в части архитектуры предприятия гармонизировать не просто несколько стандартов, а несколько совершенно разных групп описаний (viewpoints), адресующих совершенно разные интересы абсолютно разных заинтересованных сторон:
— бизнес-стратегов (VDML, гармонизирующий сам по себе довольно много, а также всяческие canvas типа http://businessmodelgeneration.com/)
— управленцев-операционщиков (BMM, ArchiMate 2.0 и т.д.. CMMN, Essence/SPEM 2.0 и BPMN 2.0 наряду со SBVR попадают сюда же). Все эти case management, critical chain — отсюда. Организационный аспект (кто что кому может поручить, кто чем распоряжается — DEMO) это тоже главным образом сюда, это «коммуникативная парадигма» процессов, хотя у Koskela на этот счёт это «инженерный» аспект дела (пункт 2.1. в http://ailev.livejournal.com/603806.html — кто что кому обещает определяется содержанием работы прежде всего).
— содержательных людей (инженеров), которых прежде всего интересуют стандарты описания продукции и управления конфигурацией, а также выбор адекватной для объектов работы технологии. Удивительно, но про «артефакты» aka «объекты работы» (work products) в стратегических или операционных стандартах практически ничего сказать нельзя, ибо детализация объектов работ в тех описаниях не предусмотрена. Тут интересны новинки типа языков описания variability, а также тренда использования онтологий (типа ISO 15926 и ISO 15629) как средств отражения разнообразия. Действительно, видов объектов в разы и разы больше, чем задействующих их видов процессов, и само это разнообразие тут является проблемой. Ну, и инженеров волнуют неожиданные (ибо природа упруго сопротивляется) изменения, отсюда issue tracking и adaptive case management в связи с управлением конфигурацией.

Нужно чётко понимать, что эти взгляды на деятельность какого-то предпринятия (ценностный, потоковый и технологический) абсолютно разные, но это не отменяет задачу создать компактный язык (мета-модель, онтологию), позволяющий отражать договорки бизнесменов (кому выгодно и кто заплатит), менеджеров (как делать эффективно и кто будет делать) и инженеров (как и из чего получить годный результат). Я не первый раз об этом пишу (вот, например, в 2008г. я писал про «коскеловщину», ср. с пунктом 2 в http://ailev.livejournal.com/603806.html — ведь ровно то же самое, хотя чуток другими словами. Собственно, это очередной пост в рамках сказанного в том давнем посте «А теперь нужно самому крепко подумать, и выдать обобщающий для всего этого месива фреймворк». Это, конечно, предмет проекта ПраксОС, praxos).

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

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

ailev.livejournal.com

Отправить ответ

avatar
  Подписаться  
Уведомление о