Бизнес архитектура компании пример

Аннотация научной статьи по экономике и бизнесу, автор научной работы — Орехов Г.С., Полякова К.О.

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

i Надоели баннеры? Вы всегда можете отключить рекламу.

Похожие темы научных работ по экономике и бизнесу , автор научной работы — Орехов Г.С., Полякова К.О.

Совершенствование информационного обеспечения бизнес-процессов строительной компании
АНАЛИЗ И ПРЕДЛОЖЕНИЯ ПО УЛУЧШЕНИЮ АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ НА ПРИМЕРЕ ООО «ДЕЛОВЫЕ ЛИНИИ»

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

АНАЛИЗ СТАНДАРТОВ И МЕТОДОЛОГИИ ПЛАНИРОВАНИЯ АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ

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

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

Текст научной работы на тему «АНАЛИЗ АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ НА ПРИМЕРЕ СТРОИТЕЛЬНОЙ КОМПАНИИ ООО «МОНОЛИТСПЕЦСТРОЙ»»

1. География внешнеэкономической деятельности Кемеровской области / http: // www.8geo.ru/kuzbass/geografiya-vneshneekommicheskoj-deyatelnosti-kemerovskoj-oblasti

2. Особое сотрудничество / http: // www.kuzbass85.ru/2014/10/22/osoboe-sotrudnichestvo/

3. Сотрудничество с Китаем / http: // lentaregion.ru/15366

Орехов Г.С. старший преподаватель кафедра МиИАЭП Полякова К.О. студент 2 курса ФГБОУ ВПО «ОГУ» Россия, г. Орел

АНАЛИЗ АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ НА ПРИМЕРЕ СТРОИТЕЛЬНОЙ КОМПАНИИ ООО «МОНОЛИТСПЕЦСТРОЙ»

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

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

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

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

Рассмотрим архитектуру предприятия на примере строительной

компании ООО «Монолитспецстрой». Она включает в себя как бизнес-архитектуру с её компонентами (организационную структуру предприятия и бизнес-процессы) так и информационно архитектуру. Миссия компании заключается в строительстве зданий и сооружений с использованием современных и перспективных технологий мирового уровня [2].

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

Рисунок 1. — Организационная структура компании «ООО «Монолитспецстрой»

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

Рисунок 2. — Бизнес-процессы компании «ООО «Монолитспецстрой»

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

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

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

2. Главный инженер получает от отдела охраны труда и ТБ заключения по техническим проектам и предоставляет техническую документацию на предмет соблюдения норм охраны труда и ТБ;

3. Главный инженер получает от главного механика анализ состояния оборудования и предоставляет планы развития производства;

4. Главный инженер получает от главного энергетика технические задания на проектирование инженерных сетей и энергетических объектов и предоставляет проекты их реконструкции;

5. Главный инженер получает от отдела МТО производственные материалы и предоставляет заявки на них;

6. Отдел МТО производит закупки всех видов материалов;

7. Отдел ПТО осуществляет сдачу объектов в эксплуатацию;

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

Рисунок 3. — Основные информационные потоки и связи

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

Таблица 1. Технологическая архитектура компании «ООО _«Монолитспецстрой»_

Класс приложений Приложения Описание

Базовые транзакционные 1 С-бухгалтерия, Microsoft Office 2013 (Microsoft ACCESS, Ecxel) Позволяют вести основную документацию компании, создавать простые базы данных и т.д.

Внутриорганизационная служба E-mail Обеспечивает коммуникацию между сотрудниками и подразделениями

Локальные сети Обеспечивают взаимосвязь пользователей и компьютеров

Google Chrome Обеспечивает выход в интернет

Windows 8.1 Операционная система большинства рядовых компьютеров

KasperskyTotalSecurity Антивирусная программа, защищающая компьютеры

Информационн ые Средства видеоконференций: видеоконференцсвязи Mind в защищенной сети ViPNet Обеспечивает видеосвязь между сотрудниками и клиентами

Системы авторизации, системы аутентификации, Технология IPsec (сетевая безопасность), физическая безопасность центров обработки данных, FoxPro, SQL-системы управления базами данных Приложения, обеспечивающие безопасность и сохранность данных (в том числе при их передаче)

Инновационные Система хранения PowerVault Хранение защищённых баз данных

PreludePackage 0.9.0 Система обнаружения вторжений

Бастион Система защиты информации, закрытые сети и каналы передачи

ERP Система управления ресурсами компании

«ГЕКТОР: Сметчик-строитель» Программа расчета строительных смет и актов выполненных работ

САП Организационно-техническая система, выполняющая автоматизированное проектирование объекта

Для совершенствования строительной компании ООО «Монолитспецстрой» и дальнейшего ее развития необходимо перераспределение полномочий между заместителями генерального директора, так как у них значительно превышены нормы управляемости. В сложившейся ситуации необходимы изменения в структурах управления, которые должны быть направлены на создание условий для выживания за счет более рационального использования трудовых и материальных ресурсов, снижения затрат и более гибкого приспособления к требованиям рыночных отношений [4].

Усовершенствованная организационная структура строительной компании представлена на рисунке 4.

Рисунок 4. — Усовершенствованная организационная структура компании ООО «Монолитспецстрой»

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

1. ИНТУИТ. Архитектура предприятия. [Электронный ресурс] // Режим доступа:

2. Абрамов Л.И., Манаенкова Э.А. Организация и планирование строительного производства. Управление строительной организацией. — М.: Стройиздат, 1990. — 395 с.

3. Вендров А.М. CASE — технологии. Современные методы и средства проектирования информационных систем.- М.: «Финансы и статистика», 1998. — 178с.

4. Артамонов А.Н., Чикишева Н.М. Совершенствование организационных структур управления строительных фирм. — СПб.: Изд-во СПбГУЭФ, 2002. -120 с.

Источник: cyberleninka.ru

Как грамотно собрать бизнес-архитектуру для системы управления проектами

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

375 просмотров

И одно из первых препятствий при внедрении ИСУП — разработка требований к системе.

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

Примеры аспектов и соответствующих им объектов

То есть не обязательно увеличивать количество объектов, вы можете просто задать необходимые свойства (см. 3-й этап).

Этап 3: Определение свойств объектов

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

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

Свойство — это параметр объекта, его характеристика.

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

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

Я выделяю две группы свойств объектов ИСУП:

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

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

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

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

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

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

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

Несмотря на некоторую сложность определения, а скорее даже сложность согласования состояний при использовании ИСУП, они значительно упрощают подготовку и восприятие управленческой отчётности.

Этап 4: Определение взаимосвязей между объектами и свойствами

Заключительный этап формирования объектной модели — определение взаимосвязей между ее элементами. Это наиболее сложный этап, так как вам необходимо проверить наличие взаимозависимостей между каждой парой объектов. Например: «цель — проект», «проект — задача», «цель — метрика». Также взаимосвязи могут быть выстроены и между объектами одного типа.

Определенные в рамках ИСУП взаимосвязи позволяют:

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

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

Таким образом, объектная модель формирует смысловой скелет ИСУП, обеспечивает полноту и достаточность требований к системе.

Для решений No-Code / Low-Code объектная модель становится каркасом, позволяющим избежать дублирования данных и не связанных ни с чем данных («повисших в воздухе»). При этом большинство No-Code- / Low-Code-решений (например, Coda, Jira) позволяет создать иерархию объектов любой сложности, настроить изменения их свойств, в том числе автоматизированный переход по фазам жизненного цикла объекта, и задать взаимосвязи между ними.

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

Еще больше актуальной информации про полезные методы и инструменты проектного менеджмента, внедрения организационных изменений и ИТ-решений ищите в нашем Телеграм-канале: Ужhttps://vc.ru/services/475397-kak-gramotno-sobrat-biznes-arhitekturu-dlya-sistemy-upravleniya-proektami» target=»_blank»]vc.ru[/mask_link]

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

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

В статье мы разбираемся с тем, как можно эффективно проектировать и использовать подобные макромодели.

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

Уточним основные понятия:

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

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

• I группа — та, с которой взаимодействует клиент;
• II группа — та, с которой клиент не взаимодействует.

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

Цели проектирования архитектуры бизнес-процессов

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

• получить общее представление о том, как работает компания;
• транслировать бизнес-модель на уровень операций;
• видеть точки пересечения процессов;
• бенчмаркинг.

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

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

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

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

Модель базовой процессной архитектуры, спроектированная в диаграмме бизнес-способностей Comindware Business Application Platform.

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

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

Цепочка создания ценности Портера является типичным примером процессной макромодели

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

• eTOM,
• ITIL,
• Process classification framework,
• SCOR,
• DCOR,
• CCRO.

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

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

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

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

Анатолий Белайчук, Chief Evangelist, Comindware

Способы моделирования процессной архитектуры

Сразу перечислим основные нотации:

• SIPOC,
• IDEF0,
• DFD,
• VAD,
• Archimate,
• Comindware Architect.

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

Диаграммы idef0 могут быть буквально нечитаемыми

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

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

Нотация Comindware Architect отличается простотой и продуманностью основных элементов.

Нотация состоит всего из 7 элементов. Может показаться, что этого мало, но, провалившись на уровень отдельного процесса, мы увидим совершенно другую картину, созданную с помощью элементов BPMN 2.0.

Все элементы BPMN 2.0 хорошо читаются, а связи между ними понятны интуитивно

BPMN 2.0 — это уже международная отраслевая нотация, созданная для проектирования процессов преимущественно в информационных системах. В Comindware Architect все процессные модели исполняемые, то есть их можно экспортировать в Comindware Business Application Platform, а затем использовать в приложении.

• поддержка многоуровневой иерархии
• отдельный элемент для показа ресурсов
• поддержка элементов BPMN 2.0
• все модели исполняемые
• проще большинства нотаций

• проприетарное использование

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

Пример реализации репозитория бизнес-процессов в Comindware Architect

Закажите демонстрацию Comindware Architect для проектирования моделей процессной архитектуры.

Елена Гайдукова, маркетолог-аналитик. Работает в сфере BPM и автоматизации процессов с 2014 года. В настоящее время является бренд-менеджером решений на базе Comindware Business Application Platform.

Похожие записи:

Опубликовано: 28 апреля 2023 в разделе BPMN, Бизнес-процессы

Лидер среди BPMS на российском рынке

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

Взгляните на цифровую трансформацию глазами ИТ-директора СургутНефтеГаз

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

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

Узнайте как правильно автоматизировать бизнес-процессы HR и в короткие сроки получить результат.

Узнайте как правильно автоматизировать процессы в бирюзовой компании и быстро получить результат.

Попробуйте инновационную платформу для разработки и запуска бизнес-приложений Comindware Business Application Platform

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

Случайные статьи

• Бизнес-процессы в строительстве — важное конкурентное преимущество
• Comindware на «Импортозамещение ИТ в новых условиях»
• Основы процессного подхода
• Аналоги SharePoint для автоматизации бизнес-процессов
• ITSM система
• Comindware оптимизирует работу сервисных центров ООН
• Comindware выпускает готовое решение для управления закупками (SRM)

Полезные страницы

• Современная BPM система
• Преимущества системы автоматизации бизнес-процессов
• CRM система с функционалом BPMS
• Карта Блога

Источник: www.comindware.ru