Моделирование основных бизнес-процессов предприятия АНХК

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

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

Анализ программ бизнес моделирования позволяет сделать  вывод, что для ведения бизнес процессов моделирования, BPwin является уникальной программой, которая позволяет создавать модели процессов и поддерживает в одной модели в дополнение к IDEF0 еще два стандарта (нотации) моделирования – DFD и IDEF3. Каждая из этих трех нотаций позволяет рассмотреть различные стороны деятельности предприятия:

1. диаграммы IDEF0 предназначены для описания бизнес-процессов на предприятии, они позволяют понять, какие объекты или информация служат сырьем для процессов, какие результаты производят работы, что является управляющими факторами и какие ресурсы для этого необходимы;
2. нотация IDEF0 позволяет выявить формальные недостатки бизнес-процессов, что существенно облегчает анализ деятельности предприятия;
3. диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации.

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

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

Модель AS-IS позволяет  выяснить, «что мы делаем сегодня» перед тем, как перепрыгнуть на то, «что мы будем делать завтра». Внедрение информационной системы неизбежно приведет к перестройке существующих бизнес-процессов предприятия. Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаком неэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (на проведение работы не оказывает влияния ее результат) и входу (объекты или информация используются нерационально) и т.д.

Для ответа на вопрос как  должно работать предприятие в будущем? Какой выигрыш (проигрыш) даст реорганизация? Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (Как будет) – модели новой организации бизнес-процессов. Модель ТО-ВЕ нужна для оценки последствий внедрения информационной системы и анализа альтернативных / лучших путей выполнения работы и документирования того, как предприятие будет функционировать в будущем. Как правило, строится несколько моделей ТО-ВЕ, из которых по какому-либо критерию выбирается наилучшая (рис. 7). Например, каждая из моделей ТО-ВЕ может соответствовать определенной информационной системе.

 

Рис. 13. Построение моделей ТО-ВЕ как результат анализа модели AS-IS

 

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

Программа BPwin предоставляет аналитику два инструмента для оценки модели – стоимостный анализ, основанный на работах (Activity Based Costing, ABC), и свойства, определяемые пользователем (User Defined Properties, UDP). ABC является широко распространенной методикой, используемой международными корпорациями и государственными организациями для идентификации движителей затрат в организации.

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

Обычно ABC применяется  для того, чтобы понять происхождение  затрат и облегчить выбор нужной модели работ при реорганизации деятельности предприятия (Business Process Re-engineering, BPR). С помощью стоимостного анализа можно решить такие задачи, как определение действительной стоимости производства продукта, определение действительной стоимости поддержки клиента, идентификация работ, которые стоят больше всего (те, которые должны быть улучшены в первую очередь), и др. в каждой из моделей AS-IS и ТО-ВЕ.

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

Кроме этого BPwin позволяет  делать достаточно эффективные оценки стоимости, но при этом не претендует на высокую точность таких оценок. Для точных вычислений затрат можно воспользоваться специализированным средством стоимостного анализа EasyABC. BPwin поддерживает двунаправленный экспорт – импорт в EasyABC. Результаты стоимостного анализа наглядно представляются на специальном отчете BPwin – ABC. ABC позволяет оценить стоимостные и временные характеристики системы. Если стоимостных показателей недостаточно, имеется возможность внесения собственных метрик – свойств, определенных пользователем UDP.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1.3 Среда бизнес моделирования BPwin

 

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

При проектировании АИС  важно разработать единые требования к системе, чтобы не было в дальнейшем необходимости переделывать проект. В современном мире компьютерных технологий важную роль играют программы бизнес моделирования, которые позволяют создать модель АИС. Для успешной реализации проекта необходимо чтобы инструментальные средства были достаточно гибкими и легко приспосабливались к изменяющимся требованиям. В результате проведенных теоретических исследований было установлено, что таким средством является Case – средство верхнего уровня-BPwin, поддерживающий методологию IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (Dataflow Diagram).

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2. Проектирование бизнес процесса  АНХК

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2.1 Описание входной информации

 

Если рассматривать хранимую информацию с точки зрения поставок, то можно выделить несколько её составляющих:

1. информация о поставщиках предполагается хранение информации о действующих в настоящее время поставщиках, наименование фирмы поставщика, юридический адрес телефон;
2. информация о поставках, сведения о том какой конкретно товар поставили, сведения о качестве этого товара, дату поставки;
3. информация об оплате;
4. информация об остатках товара на складе, какой товар находится на складе, какого производителя, в каком количестве.

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

При оформлении заказа у поставщиков заводится запись в таблице «Учет клиентов» в неё вноситься информация о клиенте. К документам предметной области можно отнести так же информацию о продукции предприятия, сформированную в виде отчетов и предложенную для ознакомления клиенту.

2.2 Описание выходной информации

 

Выходная информация представляется двумя видами:

1. в виде отчетов, которые создаются на основе требуемых запросов, по базе данных. Их цель – предоставление наглядной информации. Они могут быть не только представлены в ПК, но и распечатаны для удобства выбора;
2. в виде запросов, которые создаются в соответствиями с информационными требованиями;
3. в виде форм, предназначенных для ведения нормативно-справочной информации

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

 

2.3 Информационный анализ процессов и создание контекстной диаграммы

 

Наиболее удобным языком моделирования бизнес-процессов  является IDEF0, предложенный более 20 лет  назад Дугласом Россом (SoftTech, Inc.) и  называвшийся первоначально SADT – Structured Analysis and Design Technique. (Подробно методология SADT излагается в книге Дэвида А. Марка и Клемента Мак-Гоуэна «Методология структурного анализа и проектирования SADT» (М.:Метатехнология, 1993.) В начале 70-х годов вооруженные силы США применили подмножество SADT, касающееся моделирования процессов, для реализации проектов в рамках программы ICAM (Integrated Computer-Aided Manufacturing). В дальнейшем это подмножество SADT было принято в качестве федерального стандарта США под наименованием IDEF0.

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

Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.

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

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

Под субъектом понимается сама система, при этом необходимо точно  установить, что входит в систему, а что лежит за ее пределами, другими  словами, мы должны определить, что мы будем в дальнейшем рассматривать как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будет существенно влиять позиция, с которой рассматривается система, и цель моделирования – вопросы, на которые построенная модель должна дать ответ, другими словами, первоначально необходимо определить область (Scope) моделирования.

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

При формулировании области  необходимо учитывать два компонента – широту и глубину. Широта подразумевает определение границ модели – мы определяем, что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком Уровне детализации модель является завершенной. При определении глубины системы необходимо не забывать об ограничениях времени – трудоемкость построения модели растет в геометрической прогрессии от глубины декомпозиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему; поскольку все объекты модели взаимосвязаны, внесение нового объекта может быть не просто арифметической добавкой, но в состоянии изменить существующие взаимосвязи. Внесение таких изменений в готовую модель является, как правило, очень трудоемким процессом (так называемая проблема «плавающей области»).

Цель моделирования (Purpose). Модель не может быть построена без  четко сформулированной цели. Цель должна отвечать на следующие вопросы:

• Почему этот процесс должен быть замоделирован?
• Что должна показывать модель?

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