Страница:
♦ архитектура должна обеспечивать решение вопросов бесперебойного выполнения организациями своих функций, безопасности и восстановления в случае катастрофических событий;
♦ функциональные (бизнес-) требования должны формировать архитектуру;
♦ архитектура должна обеспечивать совместимость и взаимодействие;
♦ архитектура должна быть расширяемой, масштабируемой и адаптивной;
♦ архитектура должна быть инструментом реализации изменений;
♦ архитектура должна уменьшать сложность интеграции и способствовать улучшению качества бизнес-процессов;
♦ тенденции рынка должны учитываться при проектировании технологической архитектуры.
Объектный анализ
Процессный анализ
Понятие процесса
Компоненты процесса
Анализ процесса
Анализ топологии процесса
Анализ характеристик процесса
Анализ ошибок процесса
Анализ динамики процессов
Анализ рисков процесса
Анализ ресурсного окружения процессов
Анализ возможностей стандартизации процесса (создание эталонных, референтных моделей)
Основные методики моделирования
♦ функциональные (бизнес-) требования должны формировать архитектуру;
♦ архитектура должна обеспечивать совместимость и взаимодействие;
♦ архитектура должна быть расширяемой, масштабируемой и адаптивной;
♦ архитектура должна быть инструментом реализации изменений;
♦ архитектура должна уменьшать сложность интеграции и способствовать улучшению качества бизнес-процессов;
♦ тенденции рынка должны учитываться при проектировании технологической архитектуры.
Объектный анализ
Объектный анализ – это метод исследования не бизнес-процесса в целом, а его неделимых наименьших функциональных частей системы (на данном уровне рассмотрения) – структурных элементов (объектов), связанных между собой некими отношениями.
В качестве объектов предметной области могут рассматриваться конкретные предметы или реальные сущности, например клиент, заказ, изделия, документ и т. п. (рис. 3).
При этом различают пассивные объекты (материалы, документы, оборудование), над которыми выполняются действия, и активные объекты (организационные единицы, конкретные исполнители, программное обеспечение), которые осуществляют действия.
Каждый объект характеризуется своим состоянием (точнее набором атрибутов, значения которых определяют состояние), а также набором операций для проверки и изменения этого состояния. Каждый объект является представителем некоторого класса однотипных объектов, определяющего их общие свойства.
Качественно-количественному анализу подвергается «операционное окружение» объектов системы. Структура операционного окружения включает такие основные составляющие и их характеристики, как состав:
♦ функций, уровень их типизации, уровень автоматизации;
♦ документооборота;
♦ организационных единиц, должностей, ролей;
♦ информационных и технических средств.
В качестве объектов предметной области могут рассматриваться конкретные предметы или реальные сущности, например клиент, заказ, изделия, документ и т. п. (рис. 3).
При этом различают пассивные объекты (материалы, документы, оборудование), над которыми выполняются действия, и активные объекты (организационные единицы, конкретные исполнители, программное обеспечение), которые осуществляют действия.
Каждый объект характеризуется своим состоянием (точнее набором атрибутов, значения которых определяют состояние), а также набором операций для проверки и изменения этого состояния. Каждый объект является представителем некоторого класса однотипных объектов, определяющего их общие свойства.
Качественно-количественному анализу подвергается «операционное окружение» объектов системы. Структура операционного окружения включает такие основные составляющие и их характеристики, как состав:
♦ функций, уровень их типизации, уровень автоматизации;
♦ документооборота;
♦ организационных единиц, должностей, ролей;
♦ информационных и технических средств.
Процессный анализ
Понятие процесса
Процессный анализ предполагает исследование одного или множества бизнес-процессов организации в целом.
Варианты определения процесса следующие.
♦ Процесс – это множество внутренних шагов деятельности, начинающихся с одного и более входов и заканчивающихся созданием продукции, необходимой клиенту.
♦ Процесс – это поток работы, проходящий от одного специалиста к другому или от одного отдела к другому (в зависимости от уровня рассмотрения).
♦ Процесс – это одна или более связанных между собой процедур либо операций (функций), которые совместно реализуют некую бизнес-задачу или политическую цель предприятия, как правило, в рамках организационной структуры, описывающей функциональные роли и отношения.
♦ Процесс – это взаимонезависимый компонент производственной системы, преобразующий вход в один или несколько выходов в соответствии с предварительно установленными правилами.
♦ Процесс – это связанный набор повторяемых действий (функций), которые преобразуют исходный материал и/или информацию в конечный продукт (услугу) в соответствии с определенными критериями.
Процессный подход к моделированию позволяет:
♦ перейти от «точечного» текстового описания деятельности (Положения о подразделениях и должностных инструкций) к полному формализованному графическому описанию деятельности, интегрирующим стрежнем которого является модельное представление бизнес-процессов;
♦ выделить и использовать процессы в качестве объектов управления (раньше управляли функциями, выполняемыми тем или иным подразделением);
♦ сменить ориентацию вектора управления компании от «вертикальной» («на начальника») к «горизонтальной» («на заказчика»). Заказчик может быть как внешним, так и внутренним. Независимо от этого именно он оценивает результаты выполнения процессов, а не начальник, стоящий выше по иерархии.
Необходимость эффективного и целесообразного выбора процессов верхнего уровня при описании деятельности организации требует классифицировать их на значимые и незначимые процессы. Критерии значимости процессов могут быть различны: результативность, эффективность, гибкость, по пригодности создания ценности, по пригодности для решения стратегических задач.
С учетом роли и места в деятельности организации предлагается классификация бизнес-процессов на следующие типы:
♦ основные (ключевые) процессы – устойчивые процессы производственно-хозяйственной деятельности предприятия, ориентированные на создание конечного продукта/услуги; в составе основных процессов может быть выделен контур управляющего воздействия: собственно действие и контроль за его исполнением;
♦ обеспечивающие процессы – (правовое и кадровое обеспечение и т. д.) – процессы, обеспечивающие нормальное выполнение основных процедур и изменяющиеся в зависимости от изменения состава и технологии основных процессов;
♦ процессы внешнего взаимодействия – процессы взаимодействия с объектами, не входящими в согласованные границы описания предметной области; например, если объектом моделирования является предприятие в целом, то процессом внешнего взаимодействия будет являться процесс предоставления отчетности контрольным органам.
Также дополнительно может быть выделена категория процессов развития – процессы, определяющие тенденции и направления развития основных процессов в зависимости от анализа и прогнозируемых направлений совершенствования процедур организации.
Варианты определения процесса следующие.
♦ Процесс – это множество внутренних шагов деятельности, начинающихся с одного и более входов и заканчивающихся созданием продукции, необходимой клиенту.
♦ Процесс – это поток работы, проходящий от одного специалиста к другому или от одного отдела к другому (в зависимости от уровня рассмотрения).
♦ Процесс – это одна или более связанных между собой процедур либо операций (функций), которые совместно реализуют некую бизнес-задачу или политическую цель предприятия, как правило, в рамках организационной структуры, описывающей функциональные роли и отношения.
♦ Процесс – это взаимонезависимый компонент производственной системы, преобразующий вход в один или несколько выходов в соответствии с предварительно установленными правилами.
♦ Процесс – это связанный набор повторяемых действий (функций), которые преобразуют исходный материал и/или информацию в конечный продукт (услугу) в соответствии с определенными критериями.
Процессный подход к моделированию позволяет:
♦ перейти от «точечного» текстового описания деятельности (Положения о подразделениях и должностных инструкций) к полному формализованному графическому описанию деятельности, интегрирующим стрежнем которого является модельное представление бизнес-процессов;
♦ выделить и использовать процессы в качестве объектов управления (раньше управляли функциями, выполняемыми тем или иным подразделением);
♦ сменить ориентацию вектора управления компании от «вертикальной» («на начальника») к «горизонтальной» («на заказчика»). Заказчик может быть как внешним, так и внутренним. Независимо от этого именно он оценивает результаты выполнения процессов, а не начальник, стоящий выше по иерархии.
Необходимость эффективного и целесообразного выбора процессов верхнего уровня при описании деятельности организации требует классифицировать их на значимые и незначимые процессы. Критерии значимости процессов могут быть различны: результативность, эффективность, гибкость, по пригодности создания ценности, по пригодности для решения стратегических задач.
С учетом роли и места в деятельности организации предлагается классификация бизнес-процессов на следующие типы:
♦ основные (ключевые) процессы – устойчивые процессы производственно-хозяйственной деятельности предприятия, ориентированные на создание конечного продукта/услуги; в составе основных процессов может быть выделен контур управляющего воздействия: собственно действие и контроль за его исполнением;
♦ обеспечивающие процессы – (правовое и кадровое обеспечение и т. д.) – процессы, обеспечивающие нормальное выполнение основных процедур и изменяющиеся в зависимости от изменения состава и технологии основных процессов;
♦ процессы внешнего взаимодействия – процессы взаимодействия с объектами, не входящими в согласованные границы описания предметной области; например, если объектом моделирования является предприятие в целом, то процессом внешнего взаимодействия будет являться процесс предоставления отчетности контрольным органам.
Также дополнительно может быть выделена категория процессов развития – процессы, определяющие тенденции и направления развития основных процессов в зависимости от анализа и прогнозируемых направлений совершенствования процедур организации.
Компоненты процесса
Для задания процесса необходимо определить:
♦ название (определение) процесса;
♦ реализуемую функцию или их последовательность;
♦ участников процесса;
♦ ответственное лицо – владельца процесса;
♦ границы процесса;
♦ входные и выходные потоки, а также их поставщиков (или потребителей);
♦ требуемые ресурсы (производственные, технические, материальные, информационные);
♦ определяющую цель (цели) процесса;
♦ метрики процесса, точки и процедуры мониторинга процесса;
♦ возможные риски и влияния процесса на субъекты процесса.
Входные потоки – материалы, услуги и/или информация, преобразуемые процессом для создания выходных потоков.
Выходные потоки – результат преобразования входных потоков.
Ресурсы – содействующие факторы, непреобразуемые, чтобы стать выходным потоком (персонал, оборудование, помещения, информация и т. п.).
Владелец процесса – лицо (бизнес-роль), несущее полную ответственность за процесс и наделенное полномочиями в отношении этого процесса. Он не касается функций, выполняемых в рамках процесса отдельными департаментами. Ему важна успешная реализация всего процесса и прежде всего его производительность, эффективность и адаптируемость. Владелец процесса обеспечивает взаимодействие с поставщиками входных потоков процесса и с потребителями его результатов.
Исходя из вышеизложенного, выделяются основные составляющие модели бизнес-процесса, участвующие в ее построении:
♦ функции (действия, выполняемые участниками процесса);
♦ ресурсы (производственные, технические, материальные, системные);
♦ документы и данные (как преобразуемые в процессе, то есть входной/ выходной поток, так и непреобразуемые, то есть как ресурс);
♦ участники процесса (трудовые ресурсы);
♦ материалы/продукты, услуги (как преобразуемые в процессе, то есть входной/выходной поток).
♦ название (определение) процесса;
♦ реализуемую функцию или их последовательность;
♦ участников процесса;
♦ ответственное лицо – владельца процесса;
♦ границы процесса;
♦ входные и выходные потоки, а также их поставщиков (или потребителей);
♦ требуемые ресурсы (производственные, технические, материальные, информационные);
♦ определяющую цель (цели) процесса;
♦ метрики процесса, точки и процедуры мониторинга процесса;
♦ возможные риски и влияния процесса на субъекты процесса.
Входные потоки – материалы, услуги и/или информация, преобразуемые процессом для создания выходных потоков.
Выходные потоки – результат преобразования входных потоков.
Ресурсы – содействующие факторы, непреобразуемые, чтобы стать выходным потоком (персонал, оборудование, помещения, информация и т. п.).
Владелец процесса – лицо (бизнес-роль), несущее полную ответственность за процесс и наделенное полномочиями в отношении этого процесса. Он не касается функций, выполняемых в рамках процесса отдельными департаментами. Ему важна успешная реализация всего процесса и прежде всего его производительность, эффективность и адаптируемость. Владелец процесса обеспечивает взаимодействие с поставщиками входных потоков процесса и с потребителями его результатов.
Исходя из вышеизложенного, выделяются основные составляющие модели бизнес-процесса, участвующие в ее построении:
♦ функции (действия, выполняемые участниками процесса);
♦ ресурсы (производственные, технические, материальные, системные);
♦ документы и данные (как преобразуемые в процессе, то есть входной/ выходной поток, так и непреобразуемые, то есть как ресурс);
♦ участники процесса (трудовые ресурсы);
♦ материалы/продукты, услуги (как преобразуемые в процессе, то есть входной/выходной поток).
Анализ процесса
Для анализа процессов рекомендуется использовать опыт консультантов, эталонные и референтные модели, «check-листы» и другие статистические методы, применяемые в менеджменте качества. Аспекты анализа процесса:
♦ анализ топологии процесса;
♦ анализ характеристик процесса;
♦ анализ ошибок процесса;
♦ анализ динамики выполнения процесса (время выполнения, расход и занятость ресурсов и оборудования);
♦ анализ рисков процесса;
♦ анализ ресурсного окружения процесса;
♦ анализ возможностей стандартизации процесса (создание эталонных, референтных моделей).
♦ анализ топологии процесса;
♦ анализ характеристик процесса;
♦ анализ ошибок процесса;
♦ анализ динамики выполнения процесса (время выполнения, расход и занятость ресурсов и оборудования);
♦ анализ рисков процесса;
♦ анализ ресурсного окружения процесса;
♦ анализ возможностей стандартизации процесса (создание эталонных, референтных моделей).
Анализ топологии процесса
Анализ топологии процесса может проводиться в несколько итераций. В результате первоначальный построенный процесс может кардинально измениться. Например, функции, которые раньше выполнялись последовательно друг за другом, стали выполняться параллельно. Цель данного анализа – добиться максимально понятного течения процесса, отражающего при этом либо реальное положение вещей, либо оптимальное с учетом доступности ресурсов.
Анализ характеристик процесса
Этапы анализа характеристик:
1) определение основных характеристик (показателей) процесса;
2) определение метрик характеристик для их оценки;
3) мониторинг метрик характеристик процесса.
Основными характеристиками процесса являются следующие показатели:
♦ результативность – характеризует соответствие результатов процесса нуждам и ожиданиям потребителей;
♦ определенность – отражает степень, с которой реальный процесс соответствует описанию;
♦ управляемость – характеризует степень, в которой производится управление выполнением процесса производства требуемых продуктов/услуг, отвечающих определенным целевым показателям;
♦ эффективность – отражает, насколько оптимально используются ресурсы при достижении необходимого результата процесса;
♦ повторяемость – характеризует способность процесса создавать выходные потоки с одинаковыми характеристиками при повторных его реализациях;
♦ гибкость (адаптируемость) – способность процесса приспосабливаться к изменениям внешних условий, перестраиваться так, чтобы не снижались ни результативность, ни эффективность;
♦ стоимость процесса – определяет совокупную стоимость выполнения функций процесса и передачи результатов от одной функции к другой.
Примеры метрик характеристик процесса:
♦ отношение фактического времени выполнения процесса к плановому времени выполнения;
♦ степень автоматизации по количеству функций (количество функций с возможностью автоматизации / общее количество функций процесса);
♦ степень автоматизации по времени (суммарное время автоматизированных работ / суммарное время выполнения всех работ);
♦ отношение суммарного времени выполнения функций процесса к суммарному времени ожидания;
♦ отношение суммарного времени выполнения функций-интерфейсов взаимодействия с другими процессами к суммарному времени ожидания.
1) определение основных характеристик (показателей) процесса;
2) определение метрик характеристик для их оценки;
3) мониторинг метрик характеристик процесса.
Основными характеристиками процесса являются следующие показатели:
♦ результативность – характеризует соответствие результатов процесса нуждам и ожиданиям потребителей;
♦ определенность – отражает степень, с которой реальный процесс соответствует описанию;
♦ управляемость – характеризует степень, в которой производится управление выполнением процесса производства требуемых продуктов/услуг, отвечающих определенным целевым показателям;
♦ эффективность – отражает, насколько оптимально используются ресурсы при достижении необходимого результата процесса;
♦ повторяемость – характеризует способность процесса создавать выходные потоки с одинаковыми характеристиками при повторных его реализациях;
♦ гибкость (адаптируемость) – способность процесса приспосабливаться к изменениям внешних условий, перестраиваться так, чтобы не снижались ни результативность, ни эффективность;
♦ стоимость процесса – определяет совокупную стоимость выполнения функций процесса и передачи результатов от одной функции к другой.
Примеры метрик характеристик процесса:
♦ отношение фактического времени выполнения процесса к плановому времени выполнения;
♦ степень автоматизации по количеству функций (количество функций с возможностью автоматизации / общее количество функций процесса);
♦ степень автоматизации по времени (суммарное время автоматизированных работ / суммарное время выполнения всех работ);
♦ отношение суммарного времени выполнения функций процесса к суммарному времени ожидания;
♦ отношение суммарного времени выполнения функций-интерфейсов взаимодействия с другими процессами к суммарному времени ожидания.
Анализ ошибок процесса
Этапы анализа ошибок процесса:
1) классификация возможных ошибок процесса;
2) описание ошибок процесса;
3) выявление ошибок в процессе.
Возможные ошибки, которые могут возникать при моделировании бизнес-процессов:
♦ незавершенность. Наличие пробелов в описании процесса, например отсутствие подпроцесса, процедуры или информационного ресурса;
♦ несоответствие. Неадекватное использование информационных ресурсов в различных частях процесса. Это приводит к искаженному восприятию информации или к неясности указаний;
♦ иерархическая несовместимость. Несовместимость процесса с подпроцессами, его составляющими;
♦ «наследственная» несовместимость. Наличие конфликта между основными и последующими процессами.
1) классификация возможных ошибок процесса;
2) описание ошибок процесса;
3) выявление ошибок в процессе.
Возможные ошибки, которые могут возникать при моделировании бизнес-процессов:
♦ незавершенность. Наличие пробелов в описании процесса, например отсутствие подпроцесса, процедуры или информационного ресурса;
♦ несоответствие. Неадекватное использование информационных ресурсов в различных частях процесса. Это приводит к искаженному восприятию информации или к неясности указаний;
♦ иерархическая несовместимость. Несовместимость процесса с подпроцессами, его составляющими;
♦ «наследственная» несовместимость. Наличие конфликта между основными и последующими процессами.
Анализ динамики процессов
Динамика процессов исследуется с помощью динамической (имитационной) модели.
Имитационное моделирование – это методика, позволяющая представлять в рамках динамической компьютерной модели протекание процессов, действия людей и применение технологий, используемых в изучаемых процессах.
Динамическое имитационное моделирование позволяет генерировать конкретные бизнес-случаи выполнения бизнес-процесса на заданном интервале времени. Для построения оптимального бизнес-процесса разрабатывается несколько альтернатив, которые анализируются с помощью метода имитационного моделирования.
При использовании механизма динамического моделирования для каждого разработанного варианта модели можно получить набор статистики как по процессу в целом, так и по отдельным его элементам. Статистика включает такие параметры, как среднее время выполнения процесса, общее время ожидания, среднее время выполнения отдельных функций, коэффициент использования исполнителей и других ресурсов и т. д. Полученная статистика служит основой как для оценки текущего процесса, так и для сравнения альтернативных вариантов и выбора наиболее оптимального из них. Альтернативы могут вырабатываться индивидуально на основе эмпирических исследований либо автоматическим способом – по случайному принципу.
Имитационное моделирование – это методика, позволяющая представлять в рамках динамической компьютерной модели протекание процессов, действия людей и применение технологий, используемых в изучаемых процессах.
Динамическое имитационное моделирование позволяет генерировать конкретные бизнес-случаи выполнения бизнес-процесса на заданном интервале времени. Для построения оптимального бизнес-процесса разрабатывается несколько альтернатив, которые анализируются с помощью метода имитационного моделирования.
При использовании механизма динамического моделирования для каждого разработанного варианта модели можно получить набор статистики как по процессу в целом, так и по отдельным его элементам. Статистика включает такие параметры, как среднее время выполнения процесса, общее время ожидания, среднее время выполнения отдельных функций, коэффициент использования исполнителей и других ресурсов и т. д. Полученная статистика служит основой как для оценки текущего процесса, так и для сравнения альтернативных вариантов и выбора наиболее оптимального из них. Альтернативы могут вырабатываться индивидуально на основе эмпирических исследований либо автоматическим способом – по случайному принципу.
Анализ рисков процесса
Операционный риск можно определить как риск прямых или косвенных убытков в результате неверного исполнения бизнес-процессов, неэффективности процедур внутреннего контроля, технологических сбоев, несанкционированных действий персонала или внешнего воздействия.
Операционный риск критичен для тех процессов, которые характеризуются:
♦ значимостью для деятельности организации в целом;
♦ большим числом транзакций в единицу времени;
♦ сложной системой технической поддержки.
Выделяемые обычно риск-факторы аналогичны показателям состояния внутренней операционной среды и бизнес-процессов – объем операций, оборот, процент ошибочных действий. Управление операционными рисками – проблема, решаемая построением прозрачных и управляемых бизнес-процессов, правильной организационной структурой с опорой на экспертное знание.
Этапы анализа рисков процесса:
1) структуризация рисков;
2) описание рисков и процессов, их предотвращающих;
3) определение рисков в бизнес-процессах.
Операционный риск критичен для тех процессов, которые характеризуются:
♦ значимостью для деятельности организации в целом;
♦ большим числом транзакций в единицу времени;
♦ сложной системой технической поддержки.
Выделяемые обычно риск-факторы аналогичны показателям состояния внутренней операционной среды и бизнес-процессов – объем операций, оборот, процент ошибочных действий. Управление операционными рисками – проблема, решаемая построением прозрачных и управляемых бизнес-процессов, правильной организационной структурой с опорой на экспертное знание.
Этапы анализа рисков процесса:
1) структуризация рисков;
2) описание рисков и процессов, их предотвращающих;
3) определение рисков в бизнес-процессах.
Анализ ресурсного окружения процессов
Основу процесса составляют выполняемые функции. Для выполнения каждой из функций требуются ресурсы:
♦ людские – участники процесса (кто выполняет);
♦ производственные – станки, оборудование, компьютеры, транспорт (при помощи чего выполняет);
♦ материальные – материалы, комплектующие, энергетические ресурсы (с использованием чего выполняет);
♦ информационные – данные, документы, информация (на основании чего выполняет);
♦ интеллектуальные – знания и полномочия участников и владельца процесса.
Все эти ресурсы должны быть определены и описаны для каждой функции, выполняемой в процессе.
Например, операционное окружение таможенных процессов включает:
♦ организационное наполнение (перечень исполнителей на уровне должностных лиц и подразделений, участвующих в процессе);
♦ системное наполнение (перечень информационных и технических систем, используемых в процессе);
♦ функциональное наполнение (перечень функций, выполняемых исполнителями на уровне должностных лиц и подразделений в процессе);
♦ информационное наполнение (перечень документов и данных разного типа, используемых в процессе).
♦ людские – участники процесса (кто выполняет);
♦ производственные – станки, оборудование, компьютеры, транспорт (при помощи чего выполняет);
♦ материальные – материалы, комплектующие, энергетические ресурсы (с использованием чего выполняет);
♦ информационные – данные, документы, информация (на основании чего выполняет);
♦ интеллектуальные – знания и полномочия участников и владельца процесса.
Все эти ресурсы должны быть определены и описаны для каждой функции, выполняемой в процессе.
Например, операционное окружение таможенных процессов включает:
♦ организационное наполнение (перечень исполнителей на уровне должностных лиц и подразделений, участвующих в процессе);
♦ системное наполнение (перечень информационных и технических систем, используемых в процессе);
♦ функциональное наполнение (перечень функций, выполняемых исполнителями на уровне должностных лиц и подразделений в процессе);
♦ информационное наполнение (перечень документов и данных разного типа, используемых в процессе).
Анализ возможностей стандартизации процесса (создание эталонных, референтных моделей)
Эталоны могут служить базовыми критериями для инжиниринга бизнес-процессов. Сопоставление собственного бизнес-процесса с аналогичным процессом, взятым за образец, позволяет получить целевые, или ориентировочные, показатели. Такая процедура называется эталонным сравнением. Расхождение между характеристиками эталонного процесса и собственными показателями может подсказать, как лучше организовать у себя бизнес-процессы. Целевыми критериями при эталонном сравнении могут выступать финансовые, временные или совокупные показатели, например стоимость процесса, пропускная способность или величина входа/выхода, хотя немаловажное значение имеют и более субъективные характеристики, связанные со степенью удовлетворенности клиентов. Концепция эталонного сравнения не нова, но она всегда позволяет по-новому подойти к совершенствованию бизнес-процесса и необходимому для него сокращению времени.
При моделировании процессов «как есть» и «как должно быть» анализу подвергаются топология и ошибки процесса, а также «операционное окружение» процесса. То есть рассматриваются модели в состоянии «как есть», выявляются возможные варианты их оптимизации, их изменения и построения нового варианта операционного окружения соответствующей логики (организации) процесса.
При моделировании процессов «как есть» и «как должно быть» анализу подвергаются топология и ошибки процесса, а также «операционное окружение» процесса. То есть рассматриваются модели в состоянии «как есть», выявляются возможные варианты их оптимизации, их изменения и построения нового варианта операционного окружения соответствующей логики (организации) процесса.
Основные методики моделирования
Необходимо отметить, что постановка задачи по построению модели объекта определяется фиксированием ряда таких составляющих, как:
♦ используемые методики проектирования моделей;
♦ формализация (нотация);
♦ лингвистическое обеспечение (система классификации и кодирования).
Существуют различные подходы, или методики, к описанию архитектуры предприятия. Эти методики задают классификацию основных областей архитектуры и единые принципы для их описания во взаимной увязке друг с другом, описание используемых правил (политик), стандартов, процессов, моделей, которые используются для определения различных элементов архитектуры на разных уровнях абстракции. В качестве примеров можно указать следующие методики:
♦ методики, опубликованные аналитическими компаниями, такими как Gartner, Giga Group, МЕТА Group и др.;
♦ модель Захмана;
♦ методика TOGAF;
♦ методика POSIX 1003.23, которая основывается на разработках компании Cap Gemini, переданных для публичного использования в 1996 году.
Для государственных организаций существуют специальные методики, такие как разрабатываемая при поддержке правительства США Федеральная архитектура госорганизаций (FEAF – Federal Enterprise Architecture Framework) или используемая в Министерстве обороны США DoDAF (Department of Defence Architecture Framework).
Методика является инструментом для создания широкого спектра различных архитектур. Она, как правило, включает в себя:
♦ описание методов проектирования архитектуры в терминах использования определенных «строительных блоков»;
♦ описание того, как эти «строительные блоки» связаны между собой;
♦ набор инструментов для описания элементов архитектуры;
♦ общий словарь используемых терминов.
Методики также могут содержать список рекомендуемых стандартов и совместимых продуктов, которые могут использоваться для реализации различных элементов архитектуры. Важно понимать, что методики не только задают набор документов и планов, необходимых для описания предприятия, но и определяют, как все эти элементы описания связаны между собой.
Методики позволяют решить проблему плохого взаимопонимания между вовлеченными в этот процесс людьми, поскольку задают некий общий, одинаково понимаемый набор понятий и моделей для описания элементов архитектуры в интересах различных категорий заинтересованных сторон.
Разработка одних методик была инициирована государственными структурами, других – частным сектором и представителями индустрии.
Различные методики, как правило, ориентированы на разные аудитории потенциальных пользователей и отличаются широтой охвата проблемы, вниманием к определенным областям, хотя тенденция состоит в постепенной унификации определений, связанных с архитектурой. Некоторые из методик концентрируются на определенных секторах индустрии, преимущества других подходов состоят в более четком документировании, а третьи уделяют большее внимание процессу перехода от сегодняшнего в будущее состояние архитектуры.
Согласно описанной выше методологии моделирования авторами был изучен и опробован ряд методик по описанию бизнес-процессов, архитектуры информационных технологий предприятия.
Определение модели согласно Захману (Zachman Framework for Enterprise Architecture). Модель представляет собой общий словарь, набор перспектив или структур для описания современных сложных, корпоративных систем и преследует две основные цели: с одной стороны, логическое разбиение поставленной задачи на отдельные блоки для упрощения формирования и восприятия итогового решения, с другой – обеспечение возможности рассмотрения целостной архитектуры решения с выделенных точек зрения или соответствующих уровней абстракции.
Собственно модель представляется в виде таблицы, имеющей пять строк и шесть столбцов – «матрица» со строками в виде различных уровней абстракции (перспективами) и набором столбцов в виде представлений (областей) архитектуры. Перспективы (строки в таблице) соответствуют различному уровню управления организацией.
Первая строка соответствует уровню планирования бизнеса в целом (бизнес-модель). На этом уровне вводятся достаточно общие основные понятия, определяющие бизнес, например продукты и услуги, клиенты, расположение объектов бизнеса, а также формулируется бизнес-стратегия. Фактически данная строка определяет контекст всех последующих строк.
Вторая строка (концептуальная модель) предназначена для определения в терминах бизнеса структуры организации, ключевых и обеспечивающих бизнес-процессов.
Третий уровень (логическая модель) соответствует рассмотрению с точки зрения системного архитектора. Здесь бизнес-процессы описываются уже в терминах информационных систем, включая различные типы данных, правила их преобразования и обработки для выполнения определенных на уровне 2 бизнес-функций.
На четвертом уровне – технологической или физической модели – осуществляется привязка данных и операций над ними к выбранным технологиям реализации. Например, здесь может быть определен выбор реляционной СУБД, или средств работы с неструктурированными данными, или объектно-ориентированной среды.
Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования, топологию сети, производителя и версию БД, средства разработки и собственно готовый программный код. Многие из работ на данном уровне часто выполняются субподрядчиками.
Основные правила заполнения таблицы следующие:
♦ каждая клетка таблицы независима от других, вместе они образуют функционально полное пространство для описания системы («базис»);
♦ порядок следования колонок несуществен;
♦ каждая клетка содержит соответствующее описание аспекта реализации системы в виде определенной модели или, возможно, простого описания (текстового документа);
♦ базовые модели для каждой из колонок являются уникальными;
♦ соответствующие модели в клетках каждого ряда в совокупности образуют полное описание системы с выбранной перспективы;
♦ заполнение клеток должно проводиться последовательно «сверху вниз», попытка пропуска одного из рядов нежелательна, так как нельзя создать хорошо работающую систему, «перепрыгнув» определенные уровни ее описания на этапе проектирования.
Модель Gartner выделяет четыре связанных, взаимозависимых и усложняющихся уровня:
♦ Среда бизнес-взаимодействия (Business Relationship Grid);
♦ Бизнес-процессы и стили бизнес-процессов;
♦ Шаблоны;
♦ Технологические строительные блоки (кирпичики – bricks).
Верхний уровень Среды бизнес-взаимодействия описывает модель «виртуального» бизнеса, а также все, что связано с кооперацией предприятий и бизнесом В2В. Этот уровень соответствует понятию «отраслевой / нервной системы» взаимодействующих организаций. Он получил развитие в связи с распространением Интернета как среды взаимодействия и связан с понятиями межорганизационного взаимодействия.
Второй уровень Стили бизнес-процессов описывает, как организация выполняет свои ключевые функции, то есть включает в себя бизнес-процессы организации, такие как обработка заказа, мониторинг производственных процессов, анализ использования критически важных ресурсов, совместная работа с информацией.
Следующий уровень Шаблоны описывает модели и алгоритмы, которые могут широко использоваться для решения различных бизнес-задач. Отметим, что шаблоны охватывают не только область программного обеспечения, но и соответствующие сетевые и вычислительные ресурсы. Примерами шаблонов является трехуровневая архитектура прикладных систем (интерфейс – логика – данные), использование «толстого» клиента в архитектуре клиент/сервер, хранилища данных. Что касается приложений, то упор сделан на использовании шаблонов сервис-ориентированной архитектуры, то есть реализации приложений в виде модульного набора различных типов сервисов. Это в том числе позволяет в перспективе интегрировать приложения как Web-сервисы.
♦ используемые методики проектирования моделей;
♦ формализация (нотация);
♦ лингвистическое обеспечение (система классификации и кодирования).
Существуют различные подходы, или методики, к описанию архитектуры предприятия. Эти методики задают классификацию основных областей архитектуры и единые принципы для их описания во взаимной увязке друг с другом, описание используемых правил (политик), стандартов, процессов, моделей, которые используются для определения различных элементов архитектуры на разных уровнях абстракции. В качестве примеров можно указать следующие методики:
♦ методики, опубликованные аналитическими компаниями, такими как Gartner, Giga Group, МЕТА Group и др.;
♦ модель Захмана;
♦ методика TOGAF;
♦ методика POSIX 1003.23, которая основывается на разработках компании Cap Gemini, переданных для публичного использования в 1996 году.
Для государственных организаций существуют специальные методики, такие как разрабатываемая при поддержке правительства США Федеральная архитектура госорганизаций (FEAF – Federal Enterprise Architecture Framework) или используемая в Министерстве обороны США DoDAF (Department of Defence Architecture Framework).
Методика является инструментом для создания широкого спектра различных архитектур. Она, как правило, включает в себя:
♦ описание методов проектирования архитектуры в терминах использования определенных «строительных блоков»;
♦ описание того, как эти «строительные блоки» связаны между собой;
♦ набор инструментов для описания элементов архитектуры;
♦ общий словарь используемых терминов.
Методики также могут содержать список рекомендуемых стандартов и совместимых продуктов, которые могут использоваться для реализации различных элементов архитектуры. Важно понимать, что методики не только задают набор документов и планов, необходимых для описания предприятия, но и определяют, как все эти элементы описания связаны между собой.
Методики позволяют решить проблему плохого взаимопонимания между вовлеченными в этот процесс людьми, поскольку задают некий общий, одинаково понимаемый набор понятий и моделей для описания элементов архитектуры в интересах различных категорий заинтересованных сторон.
Разработка одних методик была инициирована государственными структурами, других – частным сектором и представителями индустрии.
Различные методики, как правило, ориентированы на разные аудитории потенциальных пользователей и отличаются широтой охвата проблемы, вниманием к определенным областям, хотя тенденция состоит в постепенной унификации определений, связанных с архитектурой. Некоторые из методик концентрируются на определенных секторах индустрии, преимущества других подходов состоят в более четком документировании, а третьи уделяют большее внимание процессу перехода от сегодняшнего в будущее состояние архитектуры.
Согласно описанной выше методологии моделирования авторами был изучен и опробован ряд методик по описанию бизнес-процессов, архитектуры информационных технологий предприятия.
Определение модели согласно Захману (Zachman Framework for Enterprise Architecture). Модель представляет собой общий словарь, набор перспектив или структур для описания современных сложных, корпоративных систем и преследует две основные цели: с одной стороны, логическое разбиение поставленной задачи на отдельные блоки для упрощения формирования и восприятия итогового решения, с другой – обеспечение возможности рассмотрения целостной архитектуры решения с выделенных точек зрения или соответствующих уровней абстракции.
Собственно модель представляется в виде таблицы, имеющей пять строк и шесть столбцов – «матрица» со строками в виде различных уровней абстракции (перспективами) и набором столбцов в виде представлений (областей) архитектуры. Перспективы (строки в таблице) соответствуют различному уровню управления организацией.
Первая строка соответствует уровню планирования бизнеса в целом (бизнес-модель). На этом уровне вводятся достаточно общие основные понятия, определяющие бизнес, например продукты и услуги, клиенты, расположение объектов бизнеса, а также формулируется бизнес-стратегия. Фактически данная строка определяет контекст всех последующих строк.
Вторая строка (концептуальная модель) предназначена для определения в терминах бизнеса структуры организации, ключевых и обеспечивающих бизнес-процессов.
Третий уровень (логическая модель) соответствует рассмотрению с точки зрения системного архитектора. Здесь бизнес-процессы описываются уже в терминах информационных систем, включая различные типы данных, правила их преобразования и обработки для выполнения определенных на уровне 2 бизнес-функций.
На четвертом уровне – технологической или физической модели – осуществляется привязка данных и операций над ними к выбранным технологиям реализации. Например, здесь может быть определен выбор реляционной СУБД, или средств работы с неструктурированными данными, или объектно-ориентированной среды.
Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования, топологию сети, производителя и версию БД, средства разработки и собственно готовый программный код. Многие из работ на данном уровне часто выполняются субподрядчиками.
Основные правила заполнения таблицы следующие:
♦ каждая клетка таблицы независима от других, вместе они образуют функционально полное пространство для описания системы («базис»);
♦ порядок следования колонок несуществен;
♦ каждая клетка содержит соответствующее описание аспекта реализации системы в виде определенной модели или, возможно, простого описания (текстового документа);
♦ базовые модели для каждой из колонок являются уникальными;
♦ соответствующие модели в клетках каждого ряда в совокупности образуют полное описание системы с выбранной перспективы;
♦ заполнение клеток должно проводиться последовательно «сверху вниз», попытка пропуска одного из рядов нежелательна, так как нельзя создать хорошо работающую систему, «перепрыгнув» определенные уровни ее описания на этапе проектирования.
Модель Gartner выделяет четыре связанных, взаимозависимых и усложняющихся уровня:
♦ Среда бизнес-взаимодействия (Business Relationship Grid);
♦ Бизнес-процессы и стили бизнес-процессов;
♦ Шаблоны;
♦ Технологические строительные блоки (кирпичики – bricks).
Верхний уровень Среды бизнес-взаимодействия описывает модель «виртуального» бизнеса, а также все, что связано с кооперацией предприятий и бизнесом В2В. Этот уровень соответствует понятию «отраслевой / нервной системы» взаимодействующих организаций. Он получил развитие в связи с распространением Интернета как среды взаимодействия и связан с понятиями межорганизационного взаимодействия.
Второй уровень Стили бизнес-процессов описывает, как организация выполняет свои ключевые функции, то есть включает в себя бизнес-процессы организации, такие как обработка заказа, мониторинг производственных процессов, анализ использования критически важных ресурсов, совместная работа с информацией.
Следующий уровень Шаблоны описывает модели и алгоритмы, которые могут широко использоваться для решения различных бизнес-задач. Отметим, что шаблоны охватывают не только область программного обеспечения, но и соответствующие сетевые и вычислительные ресурсы. Примерами шаблонов является трехуровневая архитектура прикладных систем (интерфейс – логика – данные), использование «толстого» клиента в архитектуре клиент/сервер, хранилища данных. Что касается приложений, то упор сделан на использовании шаблонов сервис-ориентированной архитектуры, то есть реализации приложений в виде модульного набора различных типов сервисов. Это в том числе позволяет в перспективе интегрировать приложения как Web-сервисы.