Файл: Вадим Алджанов итархитектура от а до Я Теоретические основы. Первое.pdf

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 18.01.2024

Просмотров: 812

Скачиваний: 3

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

•Аналитической дифференциации, разбиение общего процесса на его элементарные составляющие
•Синтетическая интеграция, обобщение родственных элементов процесса по функциональному, технологическому или прочему признаку.
Основные действия над процессами можно разделить на:
•Проектирование – создание новых процессов
•Перепроектирование – улучшение и корректировка имеющихся процессов
•Реинжиниринг – построение качественно новых процессов, на основе уже имеющихся.
Основные прикладные задачи при разработке бизнес процессов
Упорядочивание последовательности проведения операций:
•По принятию решения
•По исполнению решения
•По отражению принятых решений и результатов их исполнению
Создание методических рекомендаций и инструкций на каждой стадии:
•Документирование действий
•Формирование методических материалов
•Формирования материалов для сотрудников
Квалификационное разделение труда:
•Работа по управлению
•Работа основных специалистов
•Работа вспомогательных специалистов
•Создание ролей и формирование должностных инструкций
Видовое разделение труда:
•Обобщение однородных видов деятельности
•Концентрация специалистов на выполнение однородных действий
•Высвобождение высококвалифицированных специалистов от рутинной деятельности
•Автоматизация однородных действий
Изучение скрытых возможностей процесса
•Структурирование работы:
•Определение каждого элемента процесса
•Формирование алгоритма действий в рамках каждого элемента
Выявление и исправления проблем и дефектов.
Обмен информацией между подразделениями для понимания процесса с различных точек зрения.
Внесения ясности в понимание процессов за счет наглядности.
Для успешного внедрения процессного подхода можно использовать имеющиеся в мировой практике методики и инструменты:
•Business Process Model and Notation BPMN
•Диаграммный подход (Data Flow Diagram)
•IDEF0 и IDEF3
•Сетевой график PERT и диаграмма Gantt
•BAAN Diagram
•ARIS
Методология IDEF (нотации IDEF0 и IDEF3)
Отличительной особенностью нотации является возможность декомпозиции, т. е. каждый отдельный блок в процессе в свою очередь может быть представлен в виде отдельного процесса.


Нотация IDEF0 обычно используется для описания процессов верхнего уровня, хотя и позволяет описать всю деятельность компании. Отличительной возможностью нотации является возможность отображения не только входов и выходов каждого блока, но и «управления» и «механизмов».
Обычно имеет ограничение на девять блоков. Вместе с дополнительными возможностями повышается и требования к квалификации бизнес-аналитиков, которые занимаются моделированием процессов в нотации IDEF0.
Нотация IDEF3 чаще применяется для построения процессов нижнего уровня, могут также использовать при декомпозиции блоков процесса IDEF0. В отличие отIDEF0 данная нотация не поддерживает отображение «механизмов» и «управления», зато отображает очередность выполнения работ персоналом.
В нотации BPMN применяются логические операторы «И», «ИЛИ», а также их разновидности, как и в нотации IDEF3, но при этом существует возможность задание
циклических действий, выполняемых по определенному условию. В отличие от нотации серии
IDEF, количество элементов на диаграмме неограниченно, а для лучшего визуального восприятия существует возможность сворачивать и разворачивать определенные части под-процесса.
Нотация BPMN обычно используется для построения диаграмм процессов нижнего уровня, описание процессов верхнего уровня для неё нетипично. Поскольку детальность описания процесса достаточно велика, существуют программные решения, которые способны преобразовать диаграммы в исполняемые процессы, эти процессы затем могут быть запущенны сервером управления бизнес-процессами и обрабатываться в реальном масштабе времени.
Нотация Flowchart, известная также как «блок-схема», наверное, самый простой способ графического представления выполнения любого процесса. Блок-схемы часто применяются в учебных целях для отображения алгоритма выполнения какой-либо задачи. Для построения бизнес-процессов, в схему, как правило, вводят несколько дополнительных элементов: ответственность и ресурсы.

Нотация Flowchart наилучшим образом подходит для описания нижнего уровня процессов, но не предназначена для отображения взаимодействий на более высоких уровнях управления, поэтому многие разработчики программных продуктов применяют данную нотацию совместно с IDEF0 или разрабатывают собственную вариацию для построения процессов верхнего уровня.
Можно использовать аналог нотации Basic Flowchart c отображением ответственных за выполнение функции слева, а документов, регламентирующих её выполнение справа от функции, разделив функции на 4 типа и введя такие атрибуты как время и стоимость выполнения функции.
Процессы, построенные в нотации Flowchart наиболее наглядны и понятны даже неподготовленным сотрудникам компании.
В качестве инструментов построения бизнес процессов, можно воспользоваться: ARIS,
ELMA, Business Studio, Visio, Fox Manager и т п.
Дальнейшее развитие организации может потребовать применение специализированных решений (BPMS), которые позволяют не только моделировать процессы компании, но и внедрять их в рабочую среду и проводить мониторинг исполнения процессов. Помимо этого, ряд современных ERP решений уровня предприятия, имеют в своем составе функционал по моделированию процессов и непосредственного исполнения.


Алгоритм построения Бизнес Процессов
Для большинства организаций управление бизнес процессами можно представить в виде следующих этапов:
•Описание структуры организации «как есть»
•Анализ модели организации «как есть»
•Разработка структуры организации «как надо»
•Разработка плана перехода от модели «как есть» к модели «как надо»
•Внедрение необходимых изменений и измерений для достижения уровня «как надо»
Как одни из базовых циклов управления процессами можно выделить «Цикл Деминга»:
Диаграмма Цикл «Деминга Plan-Do-Check-Act PDCA»
Данный цикл является базовым для непрерывного процесса улучшения. Его более расширенный аналог, можно представить в виде цикла «Исикавы»:
Диаграмма Цикл «Исикавы»
Типичный бизнес-процесс включает в себя следующие компоненты:
•Владелец процесса – должностное лицо, имеющее права, полномочия и зону ответственности, а также распоряжающееся ресурсами процесса. Владелец процесса совсем не обязательно руководитель подразделения или предприятия. Это может быть просто специалист в той области, знание которой важно для качественного результата данного процесса.

•Технология процесса – порядок выполнения действий для преобразования входов в выходы.
Система показателей (метрик) процесса – показатели качества продукта, эффективности процесса, удовлетворенности потребителей.
•Управление процессом – деятельность владельца процесса по его анализу и принятию управленческих решений.
•Ресурсы процесса – материальные средства, которые владелец процесса распределяет в ходе работ по процессу.
Описание бизнес процессов можно разбить на следующие шаги:
•Описание бизнес направлений
•Описание функций в бизнес направлениях. Может состоять из «горизонтальной» и «вертикальной» составляющих.
•Описание отделов и их продукты.
•Распределение функции «как есть»
•Распределение функций «как надо»
Бизнес процессы могут разбиты на под процессы. Цель получения минимальных под-процессов идентичной функциональности. Основные критерии:
•Определены границы процесса
•Работы ясны и понятны – элементарные однородные действия (функции)
•Имеется понятие конечного результата и метод его достижения
•Действия могут быть измеряемы и управляемы
•Возможно четко определить роли сотрудников
Для построения правильных бизнес процессов, рекомендуется производить декомпозицию по нескольким параметрам и получения нескольких «деревьев» процессов (например, по продуктам и сервисам, типам операций: покупка, продажа и т п,) Кроме этого могут использоваться «Эталонные» (рекомендуемые) модели – схемы организации деятельности организаций, разработанные для конкретных отраслей и видов деятельности на основе реального опыта внедрения в различных компаниях по всему миру и включающие проверенные на практике процедуры и методы организации управления.
Цели организации обычно устанавливают, исходя из ее предназначения (миссии) и опираясь на принципы, которые культивирует руководство организации. При этом миссия в совокупности с принципами формирует политику, на основе которой и определяются цели. Политика организации (как и миссия, и принципы) определяется высшим руководством организации. Если цели и задачи установлены, но не определены способы их достижения и решения, управление останется голой теорией. Способы достижения целей и решения задач должны быть полезны для организации и не препятствовать ее развитию.
Ключ к успеху – решительная стандартизация очевидных вещей и передача их подчиненным.
Обучение и подготовка кадров способствуют формированию надежных работников, при этом, как правило, увеличивается норма управляемости (количество непосредственных подчиненных у одного руководителя). Можно организовать выполнение работ только лишь с помощью распоряжений, но такой процесс никогда не будет протекать гладко. Только опыт и квалификация работников помогают компенсировать несовершенства стандартов и регламентов.
Алгоритм построения бизнес процесса на примере процесса «Управления Инцидентами» в упрощённой схеме можно представить в следующей последовательности действий:
•Определение границ процесса
•Основные блоки процесса


•Детализирование блоков, разбивка на под-процессы
•Определение участников процесса и их роли
•Размещение документов, инструментов и действий над ними
•Определить метрики эффективности и механизмы измерений
•Связать схему с другими процессами и схемами (если таковые имеются)
•Проверить полученный бизнес процесс «тест на столе», с привлечением сотрудников ИТ и пользователей
•Утвердить процесс со стороны владельца бизнеса и передать на внедрение
Диаграмма потоков ценностей в организации
Модели Деловой Активности (Patters of Business Activities PBA)

Модели Деловой Активности позволяют ИТ департаменту предоставить картину деятельности организации, что позволяет оценить требования к сервису, спроектировать, внедрить и сопровождать на уровне, удовлетворяющий требованиям бизнеса. Модели Деловой
Активности фокусирует свое внимание на следующих параметрах, таких как:
•Частота (Frequency) – Как часто используется сервис
•Объемы (Volume) – объем активных действий, связанных с сервисом
•Продолжительность (Duration) – продолжительность активных действий, связанных с сервисом
•Место (Location) – определяет локацию (географическая точка, департамент и т п), где происходит активность,
Модели Деловой Активности также включают в себя профили пользователей (User Profile), который представляет из себя модель поведения пользователей сервиса.
Кроме выше сказанного, в модели деловой активности следует включать:
•уровень вовлеченности ИТ инфраструктуры в бизнес. Так, например, для банка, уровень вовлеченности ИТ в бизнес процесс высокий, потому что практически все бизнес процессы банка связаны с работой автоматизированной банковской программы и вовлечены порядка 70% сотрудников.
•возможности «обходных» решений при полном отказе ИТ сервисов. Обзор возможности ведения бизнеса при частичном или полном отказе ИТ инфраструктуры на определённые промежутки времени (час, день и т п).
Все это позволяет уже на начальном этапе стратегического планирования и разработки решений определить критичность тех или иных сервисов. Ниже приведены краткое описание различных моделей деловой активности различных отраслей бизнеса организации. Как пример можно рассмотреть деятельность банка.
1   ...   11   12   13   14   15   16   17   18   ...   44

Модель деловой активности Банка
Модель деловой активности Банка можно описать следующим образом:
•Деятельность банка тесно связана с функционированием ИТ инфраструктуры.
•Большая часть сотрудников банка работает с различными компьютерными системами
(Автоматизированной Банковской Программой, системами переводов и т п).
•Компьютерные системы банка часто централизованы.
•Деятельность банка жестко регламентируется со стороны контролирующих органов.
•Высокие требования по вопросам физической безопасности.
•Высокие требования по вопросам информационной безопасности.
•Высокие требования к системам обеспечения ИТ инфраструктуры.
•Высокие требования по вопросам непрерывности предоставления ИТ сервисов.
•Время работы банка регламентируется, обычно пятидневная рабочая неделя, с 09:00 до 18:00. Оставшееся время может использоваться для проведения регламентных ИТ работ
(создание резервных копий, архивирования, восстановления, проведение профилактических работ и т п)
•Наличие филиальной сети банка, географически распределенной по территории страны.
•Наличие сети банкоматов банка и POS терминалов.
Можно выделить основные бизнес приложения банка:

•Автоматизированная Банковская Программа (Automated Banking System ABS, Core Banking
System SBS) – предназначена для ведения основной операционной деятельности организации.
Характеризуется наличием механизма «закрытия дня» (Close of Business CoB) – фиксированием состояния операций. Система может иметь в своем функционале различные дополнительные возможности.
•Бухгалтерская программа (Accounting System AS) – система ведения бухгалтерского и налогового учета, и т п. Как правило, операции бухгалтерии отстают по времени от основной операционной деятельности банка. Разделение ABS и AS систем требует настройка
«однонаправленной» интеграции данных.
•Специализированные платежные системы (такие как SWIFT, SWIFT/AZIPS, HOHKS, APUS и т п) или терминалы платежных систем (Western Union, Contact и т п)
•Системы Интернет банкинга и системы онлайн оплат.
•Системы управления клиентами (CRM)
•Системы управления организацией (ERP)
•Наличие веб сайта
Профили пользователей и активности могут представлять из себя:
•Разделение по группам с фиксированными правами и доступами
•Жесткие ограничения на использование почты, интернета и систем конечных пользователей
Заключение
Суммируем все выше сказанное. С первой страницы главы и после первого определения BPM становится понятно, что ничего не понятно. Терминология и ее значение трактуется по-разному как в течении времени существования самого подхода, так и производителями «чудо» решения.
В дополнение к основному термину, время от временя вводятся новые модные словечки: BPA
(Business Process Automation или Business Process Analysis), BAM (Business Activity Monitoring), реинкарнация BPM (но уже как Business Process Monitoring) или же BPPM (Business Process
Performance Management). Объединение глянцевых, «блестящих» словечек: Business Process
Reengineering (BPR), Corporate Performance Management (CPM), Enterprise Performance
Management (EPM), Strategic Enterprise Management (SEM) и прочие великое множество. Более детально об этом можно прочитать у Ricardo Passchier в «BPM – Великая Вавилонская путаница». Даже такой корифей в этой области профессор Шеер путается в определениях и назначении ARIS (один из лидеров систем в области управления процессами).
На мой взгляд построение бизнес процессов – это правильно. Подход типа – купим
BPM/BPPM/BPMS/BPA/SEM…, наберем студентов отличников и все у нас будет великолепно – ересь. Для описания бизнес процессов компании любой сложности необходимо три инструмента: карандаш, бумага и голова. Если с первые два компонента в компаниях в избытке, то с третьим обычно наблюдается постоянная нехватка. Основной компонент – люди, работающие в данной сфере, имеющий как теоретическую базу, так и практический опыт в той или иной области бизнеса. Наибольший эффект от коллективной работы сотрудников как «вертикальной» (разные уровни иерархии), так и «горизонтальной» (сотрудники различных подразделений) составляющей организации. Первый этап – перенос на бумагу того, что имеем или создаем.
Визуальное отображение процесса помогает лучше понять все аспекты его деятельности. Так же это поможет ИТ перенести процессы на язык машин. На начальном этапе можно использовать любое офисное приложение или бесплатное решение, которое позволяет «рисовать квадратики и кружочки». Все. Далее внедряем, непрерывно отслеживаем результат и вносим изменения.
Специфическое программное обеспечение может понадобится в дальнейшем, при росте количества процессов, их повторное использование и т п. Кроме этого ряд информационных систем (ERP) имеет в своем функционале графические редакторы или программные средства, позволяющие моделировать бизнес процессы и выполнять их. Некоторые решения умеют
«читать» бизнес процесс (файл определённого формата), и мгновенно использовать его. Так на пример Microsoft System Center 2016 имеет возможность моделировать процессы