Бизнес-анализ - Моделирование

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

• Основные ценности компании
• Что это служит?
• Что отличает?
• Его ключевые ресурсы
• Основные отношения
• Каналы доставки

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

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

Цель бизнес-моделирования

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

Он используется, чтобы проверить, есть ли у заинтересованных сторон общее понимание предлагаемого «будущего решения».

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

Выполнение GAP-анализа

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

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

Если пробелов нет (т. Е. Текущее состояние соответствует потребностям бизнеса и желаемым результатам), вероятно, нет необходимости запускать ИТ-проект. В противном случае следует выявить проблемы / вопросы, которые необходимо решить, чтобы восполнить пробел.

Могут использоваться такие методы, как SWOT-анализ (сильные и слабые стороны, возможности и угрозы) и анализ документов.

Для оценки предлагаемой системы

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

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

Руководящие принципы бизнес-моделирования

Основная роль бизнес-моделирования в основном проявляется на начальном этапе и на этапах разработки проекта, и оно исчезает на этапе строительства и перехода. В основном это связано с аналитическими аспектами бизнеса в сочетании с техническим картированием приложения или программного решения.

• Domain and User variation- Разработка бизнес-модели часто выявляет области разногласий или путаницы между заинтересованными сторонами. Бизнес-аналитику необходимо будет задокументировать следующие варианты модели «как есть».

• Multiple work units perform the same function- Задокументируйте отклонения в модели КАК ЕСТЬ. Это могут быть разные подразделения или регионы.

• Multiples users perform the same work- Различные заинтересованные стороны могут выполнять аналогичную работу по-разному. Различия могут быть результатом различных наборов навыков и подходов разных бизнес-единиц или результатом различных потребностей внешних заинтересованных сторон, обслуживаемых предприятием. Задокументируйте отклонения в модели КАК ЕСТЬ.

• Resolution Mechanism- Бизнес-аналитик должен задокументировать, будет ли решение ToBe учитывать несоответствия в текущей бизнес-модели или решение потребует стандартизации. Заинтересованные стороны должны определить, какой подход им следует придерживаться. Модель To-Be будет отражать их решение.

Пример роли BA в моделировании ERP-систем

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

Требование к системе - анализ соответствия GAAP, который должен балансировать между:

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

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

Функциональный бизнес-аналитик

Знания в предметной области обычно приобретаются в течение определенного периода, когда они занимаются «делом». Например,

• А banking associate получает знания о различных типах счетов, с которыми может работать клиент (частный и корпоративный), а также подробный поток бизнес-процессов.

• An insurance sales representative может понять различные этапы оформления страхового полиса.

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

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

• А Healthcare Business Analyst Требуется базовое понимание финансовых показателей и показателей использования системы здравоохранения США, технический опыт и понимание EDI 837/835/834, руководящих принципов HIPAA, кодификации ICD - 9/10 и кодов CPT, знания LOINC, SNOMED.

Некоторые бизнес-аналитики получают знания в предметной области, тестируя бизнес-приложения и работая с бизнес-пользователями. Благодаря своим навыкам межличностного общения и анализу они создают благоприятную среду для обучения. В некоторых случаях они дополняют свои знания предметной области несколькими сертификатами предметной области, предлагаемыми AICPCU / ​​IIA и LOMA в области страхования и финансовых услуг. Есть и другие институты, предлагающие сертификацию в других областях.

Прочие основные виды деятельности

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

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

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

• Определены требования к разработчикам для участия в рабочих встречах.

• Проверить и проконтролировать, правильно ли «воспроизведены» и зафиксированы установленные вами требования в документах, описывающих будущую модель в системе (Blueprints).

• Подготовка данных и помощь в создании прототипа системы.

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

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

• Выступает в качестве ресурса поддержки ваших ИТ-специалистов при подготовке данных и фактическом выполнении функциональных и интеграционных тестов в системе.

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

Инструмент 1: Microsoft Visio

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

Step 1 - Чтобы открыть новый рисунок Visio, перейдите в меню «Пуск» и выберите «Программы» → «Visio».

Step 2 - Наведите курсор на «Бизнес-процесс» и выберите «Базовая блок-схема».

На следующем снимке экрана показаны основные разделы приложения MS-Visio.

Давайте теперь обсудим основную полезность каждого компонента -

A- панели инструментов в верхней части экрана похожи на другие программы Microsoft, такие как Word и PowerPoint. Если вы использовали эти программы раньше, вы можете заметить несколько различных функций, которые мы рассмотрим позже.

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

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

• Формы стрелок
• Backgrounds
• Основные формы блок-схемы
• Границы и названия

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

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

Инструмент 2: Enterprise Architect

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

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

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

• Business perspective - Бизнес-перспектива определяет процессы и стандарты, по которым бизнес работает на повседневной основе.

• Application Perspective - Перспектива приложения определяет взаимодействие между процессами и стандартами, используемыми организацией.

• Information Perspective - Это определяет и классифицирует необработанные данные, такие как файлы документов, базы данных, изображения, презентации и электронные таблицы, которые требуются организации для эффективной работы.

• Technology Prospective - Это определяет оборудование, операционные системы, программные и сетевые решения, используемые организацией.

Инструмент 3: Rational Requisite Pro

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

Мониторинг статуса и контроль изменений в базовом плане требований. Основными элементами являются контроль изменений и прослеживаемость.

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

В Requisite Pro пользователь может работать над документом требований. Документ представляет собой файл MS-Word, созданный в приложении Reqpro и интегрированный с базой данных проекта. Требования, созданные вне Requisite pro, можно импортировать или скопировать в документ.

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

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

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

• Общая информация о проекте
• Packages
• Общая информация о документе
• Типы документов
• Типы требований
• Атрибуты требований
• Значения атрибутов
• Межпроектная прослеживаемость

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

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