Моделирование основных бизнес-процессов предприятия (стр. 4 из 11)
Рис. 3 Схема процесса разработки КИС
Анализ требований, напротив, направлен на моделирование воображаемого, еще не существующего объекта (АИС). Т.е. сначала создается модель, а затем, на ее основании, синтезируется объект. Рассмотрим теперь обобщенную «формулу» создания АИС.
ОС->М(ОС)->М(АИС)->М’ (АИС)->М’’ (АИС)->М’’’ (АИС)->АИС
Проведя анализ организационной системы можно создать модель М(ОС). Это – модель бизнес-анализа (проблемной области).
Анализ проблемной области позволяет вычленить:
- с одной стороны, задачи и функции, реализуемые внутри ОС и функции коммуникации ОС и среды,
- с другой – устройство предметной области (в начале – на уровне концептуальной модели),
- с третьей – требования к информации и ее обработке.
Выделив среди функций те, которые подлежат автоматизации, мы получаем основу для выявления функциональных требований к системе. Остальная, собранная на этапе АПО, информация служит для поиска нефункциональных требований. В результате получаем модель АТ, как первое приближение модели АИС, М(АИС).
Углубленный анализ и проектирование, формируют, соответственно, аналитическую модель М’ (АИС), проектную модель М’’ (АИС) и модель реализации М’’’ (АИС).
Модель уровня реализации позволяет объединить собственно АИС, как совокупность программных, информационных, организационных факторов.
АИС в свою очередь представляет собой модель организационной системы М’ (ОС), замыкая цикл моделирования. Для того, чтобы прояснить связь между этими процессами, необходимо заметить, что создаваемая АИС также является моделью, по отношении к ОС. Таким образом, создавая документ АТ, мы тем самым порождаем как бы «модель второго порядка», т. к. документ АТ является ничем иным, как моделью модели ОС. Не обладая моделью АПО, мы, конечно, можем создать модель АТ. Но при этом мы рискуем тем, что при синтезе оригинала модели (т.е. АИС), не обладая знаниями об ОС, мы можем попасть в ситуацию рассогласования: результирующая АИС не будет ингерентна (согласована с) ОС и, тем самым, не станет жизнеспособной.
Процесс разработки АИС можно отобразить в виде диаграмм в программе BPwin. На рисунке 4 отображены этапы разработки АИС. Диаграммы верхнего уровня – Создание программы (рис. 4) состоит из двух диаграмм второго уровня Разработка и Тестирование (рис. 5 и рис. 6).
Рис. 4 Этап Создание программы
Разработка (рис. 5) состоит из Построения каркаса программы и Создания тела программы.
Рис. 5 Этап Разработка
Третий уровень Построение каркаса программы (рис. 6)
Рис. 6 Этап построение каркаса
Четвертый уровень (рис. 7) Создание тела программы.
Рис. 7 Создание тела программы
Пятый уровень (рис. 8) Тестирование
Рис. 8 Этап тестирования
Рассмотрев бизнес-моделирование, перейдем к бизнес-процессам. Изучение методологии бизнес-процессов приводит к возможности их деления на три категории:
- модели, преследующие цель анализа и улучшения организационной системы (например, SWOT, VCM, BPR, CPI/TQM/ISO9000, BSC),
- модели общего назначения, такие, как SADT, DFD, IDEF1, IDEF3, IDEF5 и другие,
- модели, специально разработанные для использования при автоматизации (например, ISA, BSP, ARIS, RUP).
Наиболее развитая модель описания проблемной области предлагается в методологии ARIS. Архитектура ARIS [25.5] выделяет в организации следующие подсистемы:
- Организационная. Определяет структуру организации – иерархию подразделений, должностей и конкретных лиц, многообразие связей между ними, а также территориальную привязку структурных подразделений.
- Функциональная. Определяет функции, выполняемые в организации.
- Подсистемы входов / выходов. Определяют потоки используемых и производимых продуктов и услуг.
- Информационная (подсистема данных). Описывает получение, распространение и доступ к информации (данным).
- Подсистема процессов управления. Определяет логическую последовательность выполнения функций посредством событий и сообщений. Можно сказать, что подсистема управления – это совокупность разнесенных во времени сообщений разного рода.
- Подсистема целей организации. Описывает иерархию целей, достигаемых в ходе выполнения того или иного процесса.
- Подсистема средств производства. Описывает жизненный цикл основных и вспомогательных средств производства.
- Подсистема человеческих ресурсов. Описывает прием на работу, обучение и продвижение по службе персонала организации.
- Подсистема расположения организационных структур. Описывает территориальное расположение организационных единиц.
Данное разделение является в определенной мере условным; выделенные «подсистемы» не являются подсистемами в смысле системного анализа, т.к. взаимопроникают и пересекаются. Они представляют скорее совокупность предметов исследования, разных взглядов на исследуемый объект. Принцип улучшения бизнес-процессов основывается на четыре подходах: методика быстрого анализа решения (FAST); бенчмарткетинг процесса; перепроектирование процесса; реинжениринг процесса.
В настоящее время существует ряд методик и инструментов, которые применяются при реализации преобразований. Метод построения иерархических моделей, направленн на описание и анализ бизнес-процессов как элементов экономических систем. При этом крайне важно четко сформулировать постановку задачи и цели моделирования, это определяет выбор адекватных методик и инструментальных средств.
Для решения задач функционального моделирования, то есть описания существующих процессов или процессов, которые мы стремимся получить в идеале, широко используется методология структурного анализа и проектирования технология SADT[5].
Основная идея методологии SADT – построение древовидной функциональной модели предприятия. Сначала функциональность предприятия описывается в целом, без подробностей. Такое описание называется контекстной диаграммой. Взаимодействие с окружающим миром описывается в терминах входа (данные или объекты, потребляемые или изменяемые функцией), выхода (основной результат деятельности функции, конечный продукт), управления (стратегии и процедуры, которыми руководствуется функция) и механизмов (необходимые ресурсы). При создании контекстной диаграммы формулируются цель моделирования, область (описание того, что будет рассматриваться как компонент системы, а что как внешнее воздействие) и точка зрения (позиция, с которой будет строиться модель). Обычно в качестве точки зрения выбирается точка зрения лица или объекта, ответственного за работу моделируемой системы в целом.
В дальнейшем общая функция разбивается на крупные подфункции. Этот процесс называется функциональной декомпозицией. Затем каждая подфункция декомпозируется на более мелкие – и так далее до достижения необходимой детализации описания. На рис. 2 показано дерево функций, называемое деревом узлов функциональной модели.
Рис. 9. Пример декомпозиции – диаграмма узлов функциональной модели
Каждый узел в диаграмме соответствует отдельному фрагменту описания диаграммы. Модель представляет собой совокупность иерархически выстроенных диаграмм, каждая из которых является описанием какой-либо функции или работы (activity).
Работы на диаграммах изображаются в виде прямоугольников (функциональные блоки). Каждая работа изображает какую-либо функцию или работу и именуется глаголом или глагольной фразой, обозначающей действие, например «Изготовление изделия», «Обслуживание клиента» и т.д. Стрелки помечаются существительным и обозначают объекты или информацию, связывающую работы между собой и с внешним миром. В отличие от моделей, отображающих структуру организации, работа на диаграмме верхнего уровня в функциональной модели – это не элемент управления нижестоящими работами. Работы нижнего уровня – это то же самое, что работа верхнего уровня, но в более детальном изложении.
Разрабатывая новую информационную технологию целесообразно ориентироваться на процессы, реализуемые на конкретном рабочем месте.
Под бизнес – процессом понимается поток информации, переходящий от одного рабочего места к другому. В задаче могут быть выделены несколько бизнес – процессов.
На схемах бизнес-процесс рекомендуется использовать следующие обозначения:
Внешняя сущность (рис. 10а) – объект (например, поставщик, клиент и т.д.), с которым взаимодействует данный работник;
Накопитель (рис. 10б) – любое хранилище данных;
Этап бизнеса-процесса (рис. 10в) – совокупность действий работника при выполнении конкретной процедуры (например выписка документа, формирование отчета и т.д.) В верхней части блока указывается должность работника, в нижней части находится содержание конкретных действий, реализующих процедуру;
Поток данных (рис. 10г) – характеризует связь (над стрелкой рекомендуется указать наименование конкретного документа).
Рис. 10 Условные обозначения
На рисунке 11 приведён пример построения бизнес-процесса «Оформление счета фактуры».