Моделирование бизнес-процессов позволяет проанализировать не только, как работает предприятие в целом, как оно взаимодействует с внешними организациями, заказчиками и поставщиками, но и как организована деятельность на каждом отдельно взятом рабочем месте.
Существует несколько подходов к определению понятия «моделирование бизнес-процессов»:
моделирование бизнес-процессов — это описание бизнес-процессов предприятия позволяющее руководителю знать, как работают рядовые сотрудники, а рядовым сотрудникам — как работают их коллеги и на какой конечный результат направлена вся их деятельность;
• моделирование бизнес-процессов — это эффективное средство поиска возможностей улучшения деятельности предприятия;
• моделирование бизнес-процессов — это средство позволяющее предвидеть и минимизировать риски, возникающие на различных этапах реорганизации деятельности предприятия;
• моделирование бизнес-процессов — это метод, позволяющий дать стоимостную оценку каждому процессу, взятому в отдельности, и всем бизнес-процессам на предприятии, взятым в совокупности .
Введение в BPMN. Часть 1. Основные элементы
В данной работе будут решены следующие задачи:
• раскрыты основные черты инструментальных средств моделирования;
• представлена практическая часть работы по тебе “Грузоперевозки”.
Инструментальные средства моделирования и анализа бизнес-процессов: классификация, характеристики, технология работы
Выделяют следующую классификацию:
В зависимости от места бизнес-процессов в организационной структуре компании выделяют следующие бизнес-процессы:
• горизонтальные процессы – процессы, отражающие взаимодействие по горизонтали;
• индивидуальные горизонтальные процессы – процессы, выполняемые отдельными работниками (организационными единицами);
Практическая часть
контрольная, 3 с. 180 р.
Источник: referat54.ru
Методологии моделирования и инструментальные средства реинжиниринга бизнес-процессов
Лекция 24. МЕТОДОЛОГИИ МОДЕЛИРОВАНИЯ И ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА РЕИНЖИНИРИНГА БИЗНЕС-ПРОЦЕССОВ Стандарты и методологии моделирования бизнес-процессов. История развития методологий моделирования бизнес-процессов. Методология моделирования бизнеспроцессов (Business Process Modeling); методология описания потоков работ (Work Flow Modeling); методология описания потоков данных (Data Flow Modeling).
Система ReThink как инструментальное средство реинжиниринга бизнес-процессов. Стандарты и методологии моделирования бизнес-процессов. Под методологией (нотацией) создания модели (описания) бизнес-процесса понимается совокупность способов, при помощи которых объекты реального мира и связи между ними представляются в виде модели.
Любая методология (методика) включает три основные составляющие: – теоретическая база; – описание шагов, необходимых для получения заданного результата; – рекомендации по использованию как отдельно, так и в составе группы методик. Основное в методологии – дать пользователю последовательность шагов, которые приводят к заданному результату.
Бизнес-процессы
Способность получать результат с заданными параметрами и характеризует ее эффективность. Важнейшими понятиями любого метода моделирования бизнес-процессов являются понятия объекта и связи.
Каждый объект модели отражает некоторый реальный объект, так называемой предметной области организации, люди, документы, машины и оборудование, программное обеспечение и т. д. Как правило, в рамках одного метода объекты модели, отражающие различные сущности реального мира, также являются разными. Связи предназначены для описания взаимоотношений объектов друг с другом.
К числу таких взаимоотношений могут относиться: последовательность выполнения во времени, связь при помощи потока информации, использование другим объектом и т. д. Для каждого объекта и связей характерны ряд параметров, или, как принято говорить, атрибутов, отражающих определенные характеристики реального объекта. Состав атрибутов зависит от типа, отображаемого при помощи модели, реального объекта организации.
Атрибутами могут служить такие характеристики, как номер объекта, название, описание, длительность выполнения (для функций), стоимость и др. На практике при создании моделей организации описание атрибутов объектов модели осуществляется при помощи специальных инструментальных средств моделирования бизнес-процессов.
Это позволяет сделать из простейшего «описания» бизнес-процесса более сложную «модель», на основе которой производят определенные вычисления, осуществляют анализ и оценку процесса. История развития методологий моделирования бизнес-процессов. Как же на практике осуществить реинжиниринг?
Начать необходимо с выбора наиболее подходящей методологии описания (или моделирования) бизнес-процессов. Наиболее простыми (но подчас весьма эффективными, особенно на начальном этапе реинжиниринга) являются: 1. Блок-схема бизнес-процесса, состоящая из прямоугольников (обозначающих действия), ромбиков (обозначающих принимаемые решения) и стрелок, соединяющих эти элементы между собой и друг с другом; 2. Словесное описание бизнес-процесса, отвечающая, на вопросы что, кто, где, как, зачем и почему, а также каковы затраты времени и денежных средств на принятие решений, ожидание и осуществление действий в бизнес-процессе.
К сожалению, кроме несомненных достоинств – простоты и очевидности – эта методология является недостаточно наглядной и удобной для определения эффективности реализации бизнес-процесса. Поэтому был разработан ряд более эффективных 1 методологий, наиболее распространенными представленные в таблице 1, методологии: из которых являются следующие, Таблица 1. История развития методологий моделирования бизнес-процессов.
Основу многих современных методологий моделирования бизнес-процессов составили методология SASD и методология SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования) и алгоритмические языки, применяемые для разработки программного обеспечения. Методология структурного анализа и проектирования (SASD).
Эта методология основана на классической и весьма успешной методологии структурного проектирования программного обеспечения и информационных систем (ИС). Так как в разработке прикладных программ и ИС приходится постоянно иметь дело с различными информационными процессами, то неудивительно, что разработанные для этого методологии оказались вполне применимыми и для моделирования бизнес- процессов.
Методология SADT представляет собой дальнейшее развитие методологии структурного анализа и проектирования SASD. 2 В таблице 1 история развития методологий моделирования бизнес-процессов представлена в сжатом виде. Для наглядности параллельно приведена история развития подходов к управлению качеством.
В настоящее время для описания, моделирования и анализа бизнес-процессов используются несколько типов методологий. К числу наиболее распространенных типов относятся следующие методологии: – моделирования бизнес-процессов (Business Process Modeling); – описания потоков работ (Work Flow Modeling); – описания потоков данных (Data Flow Modeling).
Методологии моделирования бизнес-процессов (Business Process Modeling): Методология IDEF. (IDEF — методологии семейства ICAM (Integrated ComputerAided Manufacturing) для решения задач моделирования сложных систем, отсюда название: Icam DEFinition — IDEF другой вариант — Integrated DEFinition)). Это, пожалуй, наиболее глубоко проработанная и наиболее обширная методология, которая позволяет описывать не только бизнес-процессы, но и функциональные блоки (например, маркетинг или финансы), различные объекты в компании и действия над ними (например, весь комплекс процессов обработки и выполнения заказа клиента), а также состояние и динамику развития бизнес-единиц компании и компании в целом.
Наиболее широко используемая методология описания бизнес-процессов – стандарт США IDEF0. С момента разработки стандарт не претерпел существенных изменений. В настоящее время развитие методологии IDEF0 сопряжено с совершенствованием поддерживающих ее инструментов – программных продуктов для моделирования бизнес-процессов (например, BPWin 4.0, ProCap, IDEF0/EM Tool и др.).
Методология IDEF0 предоставляет аналитику широкие возможности для описания бизнеса организации на верхнем уровне с акцентом на управление процессами. Нотация позволяет отражать в модели процесса обратные связи различного типа – по информации, управлению, движению материальных ресурсов.
Продуманные механизмы композиции модели процесса в IDEF0 предназначены для высокоуровневого описания бизнеса компании. Их основное преимущество состоит в возможности описывать управление процессами организации.
Методология IDEF состоит из 14 компонент, наиболее важными из которых являются: — IDEF0 (методология моделирования функциональных блоков); — IDEF1 (методология моделирования информационных потоков в компании); — IDEF2 (методология моделирования динамики развития компании); — IDEF3 (методология документирования бизнес-процессов в компании); — IDEF4 (методология описания различных объектов в компании и действий над ними); — IDEF5 (методология описания текущего состояния компании и тенденций его изменения). 3 Методологии описания потоков работ (Work Flow Modeling) Одна из важнейших методологий описания процессов – IDEF3.
Предназначена для описания рабочих процессов или, иными словами, потоков работ. Стандарт IDEF3 близок к алгоритмическим методам построения схем процессов и стандартным средствам создания блок-схем. Следует отметить, что стандарт включает два существенно различающихся метода описания процессов. Ниже рассмотрим метод, получивший наибольшее распространение.
Основу методологии IDEF3 составляет построение моделей процессов по принципу последовательно выполняемых во времени работ (функций, операций). Можно утверждать, что IDEF3 лежит в основе популярной в настоящее время методологии ARIS еЕРС.
Методологии описания потоков данных (Data Flow Modeling) Еще одна группа методологий, активно используемых на практике, – нотации DFD (Data Flow Diagramming), предназначенные для описания потоков данных. Они позволяют отразить последовательность работ, выполняемых по ходу процесса, и потоки информации, циркулирующие между этими работами.
Кроме того, нотация DFD предоставляет возможность описывать потоки документов (документооборот) и материальных ресурсов (например, движение материалов от одной работы к другой). Методология DFD может эффективно использоваться для описания процессов при внедрении процессного подхода к управлению организацией, так как позволяет максимально снизить субъективность описания бизнес-процессов.
С помощью схемы процессов в DFD выявляют основные потоки данных, что важно для последующего создания моделей структуры данных и разработки требований к информационной системе организации. Задачи, которые приходится решать в ходе реинжиниринга, обычно характеризуются высокой степенью сложности и большой ответственностью.
Опыт неудач первых лет развития этого направления показал, что успешный реинжиниринг не может быть осуществлен без твердой методологической основы. Приведенные выше методологии проведения реинжиниринга бизнес-процессов, разработаны ведущими консалтинговыми фирмами мира.
Исторически большинство консалтинговых фирм основывали свои подходы к реинжинирингу, исходя из CASE-технологии разработки информационных систем. Здесь можно отметить такие известные фирмы, как Gemini Consulting методология Construct и Andersen Consulting — методология Eagle.
П.Хармон отмечает их ориентацию на профессионалов в области информационных технологий и направленность на разработку поддерживающих информационных систем. Однако в проведении реинжиниринга участвуют специалисты двух типов профессионалы в области реконструируемого бизнеса и разработчики информационных систем.
Опыт реинжиниринга показывает, что по-настоящему успешное и новаторское внедрение информационных технологий является уникальным творческим процессом: управляющие компаний и специалисты-технологи, знакомясь с методами информационных технологий, сами делают открытия относительно возможностей их использования в своем конкретном бизнесе. В то же время, создание высококачественных информационных систем требует участия профессионалов в области информационных технологий.
Возникает проблема поиска общего языка, которая стоит на пути интеграции современных технологий моделирования и разработки сложных систем: объектноориентированные методы, CASE-технологии (англ. Computer-Aided Software Engineering набор инструментов и методов программной инженерии для проектирования программного обеспечения, который помогает обеспечить высокое качество программ, отсутствие ошибок и простоту в обслуживании программных продуктов), инженерия знаний, имитационное моделирование процессов и методы быстрой разработки 4 приложений RAD (Rapid Application Development — концепция создания средств разработки программных продуктов).
Именно эта тенденция и наблюдается сейчас в развитии методологий и инструментальных средств реинжиниринга бизнес-процессов. Объектно-ориентированное моделирование признано сегодня базовой методологией BPR. Традиционно, создавая информационные системы компаний, разработчики отталкивались от данных.
В результате, используемые ими подходы к моделированию систем были ориентированы на описание данных о сущностях реального мира и их взаимосвязей, но не на поведение этих сущностей. Поскольку реинжиниринг ориентирован на процессы, а не на данные, традиционные подходы оказались неадекватны.
Объектно-ориентированный подход является единственным пока подходом, позволяющим описывать как данные о сущностях, так и их поведение. Кроме того, он обеспечивает создание прозрачных, легко модифицируемых моделей бизнеса и информационных систем, допускающих повторное использование отдельных компонентов.
CASE-технологии использовались в реинжиниринге практически с момента его появления. Однако их ориентация на разработчиков информационных систем привела к тому, что теперь их начинают объединять с другими современными технологиями — в первую очередь, с объектно-ориентированными.
Имитационное моделирование обеспечивает не только наиболее глубокое представление моделей для непрограммирующего пользователя, но и наиболее полные средства анализа таких моделей. Модели создаются в виде потоковых диаграмм, где представлены основные рабочие процедуры, используемые в компании, описано их поведение, а также информационные и материальные потоки между ними.
Впрочем, построение реальных имитационных моделей довольно трудоемкий процесс, а их детальный анализ, выходящий за рамки простого сбора статистики по срокам и стоимостям, зачастую требует от пользователя специальной подготовки. Для описания рабочих процедур может понадобиться дополнительное программирование.
Чтобы преодолеть эти трудности, сегодня начинают использовать методы инженерии знаний. Во-первых, с их помощью можно непосредственно представлять в моделях плохо формализуемые знания менеджеров о бизнес- процессах и, в частности, о рабочих процедурах.
Во-вторых, решается проблема создания интеллектуального интерфейса конечного пользователя со сложными средствами анализа моделей. Методы быстрой разработки приложений позволяют сокращать время создания поддерживающих информационных систем и, следовательно, используются не только в ходе реинжиниринга компании, но и на этапе эволюционного развития, сопровождающегося постоянными модификациями и улучшениями информационных систем компании.
Современный период характеризуется активным переходом к использованию интегрированных методологий и инструментальных средств. Система ReThink как инструментальное средство реинжиниринга бизнеспроцессов.
С интегрированным подходом к поддержке реинжиниринга можно ознакомиться на примере одного из перспективных инструментальных средств реинжиниринга бизнеспроцессов — системы ReThink (перевод с англ. – пересматривать, обдумывать, переосмысливать), разработанной фирмой Gensym (США). В этой системе объединены возможности ключевых современных информационных технологий: графический объектно-ориентированный язык для описания моделей и проектов, средства анимации и имитационного моделирования реконструируемых процессов, методы искусственного интеллекта для полного и адекватного представления экспертных знаний о процессах.
Все это открыло доступ к непосредственному моделированию и реконструированию бизнеспроцессов новой группе пользователей — менеджерам. Сочетание прозрачных средств интерактивной графики с возможностями моделирования процессов в реальном времени 5 позволяет им самостоятельно, без помощи программистов, воплощать свои идеи в виде работающих моделей процессов.
Система ReThink построена на базе инструментального комплекса и является проблемно-ориентированным приложением, позволяющим разработчикам использовать не только специализированные средства моделирования бизнес-процессов, но и универсальные средства комплекса по созданию интеллектуальных объектноориентированных систем управления реального времени. Для представления моделей бизнес-процессов используются диаграммы, состоящие из блоков и соединений.
Блоки представляют задачи в бизнес-процессах, а соединения потоки сущностей: документов, информации, а также предметов, фигурирующих в бизнесе, — например, запасных частей или упаковок с отпускаемой продукцией. В системе реализован ряд стандартных блоков, которые могут быть использованы в качестве сборочных элементов для построения работающих моделей практически любых процессов, например: источник заявок, принятие решения, обработка задания.
Свойства и поведение блоков могут описываться как точными, так и случайными величинами. В случае необходимости разработчик переопределяет поведение блоков или задает новые их классы с помощью встроенных базовых средств.
Объектная ориентация системы ReThink позволяет создавать понятные и довольно наглядные модели бизнес-процессов, что упрощает освоение и использование системы непрограммирующими пользователями. Объекты, построенные в результате моделирования бизнес-процессов, становятся естественной основой для проектирования информационных систем поддержки этих процессов.
В этом смысле средства системы ReThink могут рассматриваться как развитие CASE-средств. ReThink поддерживает анимацию потоков работ в ходе моделирования деятельности компании. Благодаря этому менеджер имеет возможность непосредственно наблюдать функционирование моделей, что повышает степень его доверия к результатам моделирования.
Данная система обеспечивает создание иерархических моделей, позволяющих описывать процессы с различной степенью детализации. Это гарантирует простоту и естественность при создании сложных моделей больших компаний (рисунок 2). Рисунок 2. Пример иерархической модели.
6 Все элементы моделей, включая ресурсы процессов, могут модифицироваться непосредственно во время исполнения, результаты изменений можно увидеть сразу же после их введения. Система ReThink позволяет формировать стоимостные и временные характеристики различных проектов для их объективного сравнения, а также проверять гипотезы типа «что, если», для проверки которых есть функция: сценарии.
Сценарии позволяют исследовать зависимость поведения одной и той же модели от поведения внешнего мира, (например, частота поступления заявок, их сложность и т.д.), а также от каких-либо параметров этой модели (например, количества транспортных средств или численности служащих, занятых оформлением заказов). Варьируемые параметры и измеряемые показатели выносятся на отдельное окно сценария, после чего в результате прогона модели автоматически формируется отчет.
Кроме этого, система позволяет использовать сценарии для объективного сравнения альтернативных проектов: один и тот же сценарий, описывающий некоторое заранее заданное поведение внешнего мира, может применяться для прогона различных моделей. Результаты вынесенные в отчет, являются основой для сопоставления и оценки этих моделей.
При создании системы ReThink фирма Gensym не ставила своей целью предложить какую-либо конкретную методологию реинжиниринга. Ее задача — создание удобного универсального средства для реализации различных методологий.
Система адресована, в первую очередь, консалтинговым фирмам и информационным подразделениям крупных компаний для воплощения их оригинальных идей в области реинжиниринга. Сегодня ReThink используется в ряде компаний, среди которых патентное ведомство США и компания Xerox, осуществившая реинжиниринг отделения по закупке сопутствующих материалов с годовым оборотом в 3 млрд. долларов.
В компании Xerox при проведении реинжиниринга сначала использовался пакет ABC FlowCharter, а построенная модель работы отделения включала 17 процессов и 314 рабочих процедур. Анализ модели показал, что 70% процедур оказались непроизводительными. Затем была разработана новая модель процессов закупки, включающая всего 42 рабочие процедуры.
Столкнувшись с таким существенным сокращением количества процедур, руководство компании поставило вопрос о работоспособности новой организации: не возникнут ли перед компанией серьезные непредвиденные проблемы после того, как она сделает основные капиталовложения в реконструкцию отделения? Чтобы обосновать предложенный проект, было решено использовать систему ReThink, с помощью которой предполагалось исследовать имитационную модель планируемой организации работы отделения. В результате несколько процессов пришлось снова перепроектировать, что привело к выигрышу в качестве проекта, а, следовательно, снизило риск неудачи при проведении реинжиниринга. 7
Источник: spravochnick.ru
Современные инструментальные средства моделирования бизнес-процессов. Как выбирать инструментальную среду для бизнес-моделирования
Одним из важнейших этапов решения задачи построения модели бизнес-архитектуры является выбор инструментальной среды.
Для автоматизации моделирования процессов сложился специальный класс программных продуктов. Наиболее известными являются такие продукты, как ARIS, Software Architect, BPWin (новое название – AllFusion Process Modeler), хотя в большом количестве случаев стандартных графических пакетов типа Microsoft Visio, текстового редактора и электронной таблицы бывает достаточно. И в данной книге мы не будем останавливаться на сравнительном анализе этих и других средств и отсылаем читателя к специализированным публикациям.
В данной главе не будет «навязываться» какое-либо конкретное инструментальное средство, а в первую очередь будут определены основные подходы, принципы и рекомендации, которые целесообразно использовать заказчиком и исполнителем при формировании профиля комплекса инструментальных средств моделирования.
К числу обязательной рекомендации для заказчика и исполнителя при осуществлении выбора относится соблюдение принципа учета всех привходящих факторов, связанных с решаемой задачей по созданию модели бизнес-архитектуры предприятия. Огрубленно данные факторы отражают два ключевых момента («внутренних» и «внешних»):
«внутренние» – потребности и возможности предприятия, связанные с созданием моделей бизнес-архитектуры;
«внешние» – возможности современных инструментальных средств.
Данная глава посвящена всестороннему рассмотрению этих факторов и последующему их учету при принятии окончательных решений по выбору инструментальной среды.
К числу основных «внутренних» факторов, влияющих на выбор заказчиком инструментальной среды моделирования, следует отнести:
производственную необходимость;
бюджетные ограничения;
уровень текущей проработки задач по моделированию и оптимизации;
уровень подготовки персонала;
предыдущие вложения;
характеристики программно-аппаратной платформы и т. д.
По каждому из вышеперечисленных факторов можно дать следующие комментарии.
Производственная необходимость. Несомненно, что постановки задач по моделированию определяют необходимый функционал инструментальной среды. Очевидно, что при всех прочих параметрах не следует с «переплатой» приобретать инструментальную среду с избыточным для решаемой задачи функционалом. Например, если не планируется осуществлять имитационное моделирование, то не следует приобретать данный модуль. Если моделирование нацелено в первую очередь на создание информационных систем, то необходимо подбирать инструментальные средства, сориентированные на эти цели.
Для качественного обоснования производственной необходимости выбираемой конфигурации средств моделирования необходимо:
1) четко сформулировать все «производственные» постановки задач по моделированию;
2) определить под каждую постановку задачи необходимый функционал по моделированию, который должен поддерживаться инструментальной средой моделирования;
3) сопоставить функционал по моделированию возможных к использованию инструментальных средств (модулей инструментальных средств).
Уровень текущей проработки задач по моделированию и оптимизации. Данный фактор в значительной степени связан с вышеописанным фактором «производственной необходимости». Этот фактор определяется следующими ключевыми обстоятельствами:
пройденными (реализованными) в модели бизнес-архитектуры уровнями детализации бизнес-процессов и их базовых компонент;
сформулированными целями по дальнейшей детализации моделей бизнес-процессов и их базовых компонент;
разработанными подходами, включая алгоритмические решения, по оценке состояния бизнес-процессов и их оптимизации.
В определенной степени можно утверждать, что уровень сложности привлекаемых средств моделирования должен соответствовать уровню зрелости (культуры) предприятия, а именно проработки и формализации текущих проблем бизнес-процессов организации.
Очевидно, при отсутствии либо неполноте описательных моделей бизнес-процессов совершенно нет необходимости «гнаться» за функционалом, который должен реализовываться на последующих этапах, например функционально-стоимостной анализ, имитационное моделирование и т. д. В том случае, если нет информации о временных и стоимостных показателях выполнения бизнес-функций и поддерживающих их организационных и технологических ресурсах, то соответственно нет необходимости приобретения дорогостоящих технологий, которые обеспечивают различную логику и алгоритмы обсчета временных, стоимостных и других количественных показателей, равно как и последующей их оптимизации. Аналогично, если не определен и не формализован перечень показателей оценки деятельности, равно как и порядок их получения, то совершенно бессмысленно форсировать закупки программных средств, специализированных на решение только этой задачи.
Бюджетные ограничения. Стоимость инструментальных средств различных производителей может существенно различаться. При этом бюджетные затраты предприятия, связанные с выбором инструментальной среды, будут определяться не только начальными инвестициями на его приобретение, но и последующими затратами на техническую поддержку, обучение персонала, возможную модернизацию программно-аппаратной платформы, потенциальный «апгрейд» и т. д. При этом необходимо отметить, что во многих случаях дистрибьюторы, заинтересованные лишь в продаже программного обеспечения, могут в явном виде не обозначать всех финансовых «обременений», которые могут последовать после этапа покупки инструментального средства. Для точного обсчета финансовой нагрузки могут использоваться специализированные методики, например ТСО. По этой причине общие объемы бюджета предприятия и их соизмеримость с потенциальной финансовой нагрузкой, которая последует за выбором инструментальной среды, могут сыграть главную роль в приятии окончательного решения.
Уровень подготовки персонала. Данный фактор чаще всего забывается заказчиком. Особенно критичным этот фактор является для тех предприятий, которые рассчитывают на самостоятельное решение задач либо по разработке, либо по поддержке модели бизнес-архитектуры. При всей дружелюбности пользовательского интерфейса, средств разработки требуются специальная и общесистемная подготовки для исполнителей работ по моделированию, равно как и проведение обучения пользователей.
Как правило, чем шире возможности инструментальной среды, тем выше выдвигаются требования к техническому персоналу и пользователем. Соответственно, более длительными оказываются сроки подготовки. Во многих случаях обеспечение адекватности компетенции персонала организации сложности инструментальной среды моделирования не может быть решено в приемлемые сроки только проведением обучения. Вполне возможно, что потребуется более радикальное решение проблемы недостаточного уровня технологической компетенции организации, а именно наем уже подготовленных квалифицированных специалистов.
Понятно, что при наличии существенных финансовых ограничений на обучение, сжатых сроков внедрения системы при значительной длительности процесса обучения, организационных сложностей с подбором специалистов либо расширением штатов «человеческая» проблема может стать основным препятствием на пути внедрения нужной для организации инструментальной среды моделирования.
В целом необходимо отметить, что игнорирование человеческого фактора может либо на начальных этапах, либо в «отложенном» режиме создать проблемы по созданию и эффективному использованию модели бизнес-архитектуры предприятия. Недостаточный уровень знания общесистемных и прикладных возможностей среды моделирования породит неустойчивость работы системы, раздражение, боязнь и как следствие отторжение конечными пользователями предлагаемого программного обеспечения.
Предыдущие вложения. Вполне возможна ситуация, когда на предприятии уже проводились работы по моделированию бизнес-процессов и, соответственно, были осуществлены определенные вложения. Данные вложения могут быть связаны с закупками программного обеспечения и технических средств, обучением технического персонала, пользователей, оплатой технической поддержки, созданием специальных приложений и т. д. Не менее значимыми, чем финансовые затраты, являются обстоятельства, связанные с накоплением значительного количества информации («знаний») в форматах ранее использованной инструментальной среды. В том случае, если данные форматы являются «автономными», потенциальный переход в новую инструментальную среду может потребовать разработки специальных средств преобразования. Другой важной составляющей проблемы трансформации знаний бизнес-процессов в иную инструментальную среду является «ломка» привычек пользователей, связанных с применением ставших «традиционными» в организации форм представления информации по бизнес-процессам.
В зависимости от глубины и значимости технологической и «культурной» составляющей истории формализации бизнес-процессов на предприятии должны приниматься взвешенные решения по выбору новой инструментальной среды моделирования. В том случае, если предыдущие вложения очень значительные, то вполне возможно, что организации следует «смириться» с несовершенством используемых технологий и отказом от перехода на принципиально новую инструментальную платформу. В случае если существует целесообразность миграции на другую платформу, то в число ключевых параметров по выбору новой платформы при наличии нескольких альтернатив должны попасть следующие условия к кандидату на замену:
уровень ее совместимости со старой средой моделирования;
уровень «похожести» интерфейса с заменяемой платформой;
схожесть требований к квалификации технического персонала и конечных пользователей с заменяемой платформой;
отсутствие необходимости модернизации общесистемной программно-аппаратной платформы;
возможность использования существующей инфраструктуры технической поддержки и обучения.
Характеристики программно-аппаратной платформы. Чем сложнее инструментальная среда моделирования, тем оно «тяжелее» с точки зрения требования к общесистемной программно-аппаратной платформе. При выборе инструментальной среды модели необходимо оценить следующие вопросы:
требования к технической платформе;
требования к общесистемному программному обеспечению;
требования к телекоммуникационному обеспечению;
возможности по обеспечению информационной безопасности;
количество мест установки пользовательских приложений.
В том случае если текущая конфигурация программно-аппаратной платформы предприятия не может обеспечить установку инструментальной среды на планируемом количестве пользовательских мест, то предприятие должно принимать управленческое решение в отношении качественно-количественной модернизации своего ИТ-парка. Соответственно, при наличии в компании финансовых и организационных ограничений на модернизацию программно-аппаратной платформы ИТ-парк может стать основным препятствием на пути выбора требуемой инструментальной среды моделирования.
В настоящее время у многих заказчиков существует устоявшееся представление, что для построения модели бизнес-архитектуры предприятия достаточно использования какого-то одного инструментального средства. Вместе с тем это далеко не так. Специфичность областей и способов моделирования обусловливало появление линейки программных средств поддержки процесса моделирования.
В ряде случаев могут существовать такие постановки задач, которые могут потребовать для своей реализации не одного, а нескольких программных средств поддержки процесса моделирования. Подбор нескольких программных средств определяется оптимальностью решения составных частей поставленной задачи.
В частности, если заказчиком ставится задача «сквозного» моделирования с последующей автоматизацией тех или иных функций, то вполне очевидно, что при наличии двух объектов моделирования (бизнес-логики деятельности организации и функционирования информационной системы) целесообразно использовать как минимум два класса средств:
программные средства моделирования (формализации), нацеленные на общее описание бизнес-процессов;
программные средства моделирования (формализации), нацеленные на разработку автоматизированных информационных систем.
Аналогичная ситуация сложилась и при необходимости использования нескольких разнопрофильных средств моделирования при исследовании различных сторон одного и того же объекта. Например, при постановке задачи анализа структуры и поведенческой (динамической) составляющей моделируемого объекта должно быть предусмотрено использование как минимум двух классов программных средств (модулей):
средств формализованного описания статической структуры бизнес-процесса;
средств динамического анализа (имитационного моделирования).
Поэтому правильной для заказчика является постановка задачи не приобретения одного инструментария, а формирования единой корпоративной среды моделирования, предусматривающей использование нескольких программных средств (профиля средств) моделирования бизнес-архитектуры.
Принципиальное значение для определения архитектуры среды моделирования бизнес-процессов имеет общая стратегия предприятия в части создания прикладных программных средств. В общем случае существуют две ключевые стратегии в части создания прикладного ПО:
опора на заказные разработки;
опора на промышленно поддерживаемые инструментальные средства, предусматривающие возможность настройки на прикладные задачи.
Разумеется, возможен и промежуточный вариант, предусматривающий сочетание двух вышеуказанных стратегий.
В случае если на предприятии культивируется стратегия заказных разработок, то соответственно вполне возможен выбор по заданной конфигурации постановок задач более простых и соответственно более дешевых средств моделирования. При этом недостающий функционал для решения задач моделирования может быть восполнен за счет написания дополнительных скриптов.
В том случае если приоритетной является стратегия использования готовых промышленно поддерживаемых инструментальных средств, то среди перечня альтернативных программных средств предпочтение будет отдаваться тем решениям, которые обладают наибольшей универсальностью.
Современные взгляды на построение АИС предусматривают приоритетную реализацию стратегии использования промышленно поддерживаемых технологий. Основные издержки и риски создания заказных разработок в области моделирования бизнес-процессов связаны с:
низким уровнем прогнозирования сроков завершения работ по созданию самописных скриптов;
вероятностью наличия скрытых ошибок в ПО;
необходимостью поддержки синхронности модернизации ПО с учетом развития общесистемных технологий;
высокой зависимостью от разработчика;
недостаточной полнотой документирования разработки;
трудно прогнозируемыми затратами на документирование, тестирование, обеспечение качества и т. д.;
возможностью срыва сроков построения модели;
сложно прогнозируемым уровнем технической поддержки и т. д.
Риски и издержки, связанные с использованием промышленно поддерживаемых программных средств моделирования, могут заключаться в следующем:
неполнота функционала для учета специфики постановки задач;
необходимость проведения доработок для интеграции с существующими информационными системами;
избыточность функционала, что усложняет работу пользователей;
затраты на техническую поддержку;
диктат производителя в части апгрейда версий ПО;
недостаточная гибкость;
возможность ухода с рынка производителя ПО и соответственно возможность потери технической поддержки и восстановление заказчиком утерянных дистрибутивов и т. д.
Особое внимание следует обратить на последнее из приведенных обстоятельств. Уход с рынка компании-производителя может иметь катастрофические последствия для существования разработанной модели бизнес-архитектуры предприятия. Трудно требовать от заказчика предвидения в изменениях рынка инструментальных средств. Общей рекомендацией в данной ситуации может быть ориентация на крупных производителей, имеющих «долгую» историю существования на ИТ-рынке, а также широкое распространение своей продукции.
В реальности в чистом виде на большинстве предприятий не используется только одна из вышеприведенных стратегий. Как правило, на практике наблюдается сочетание «самописных» разработок и промышленных инструментальных средств. По этой причине приверженность заказчика к одной из двух стратегий создания модели бизнес-архитектуры будет проявляться в долевом отношении количества функций, реализованных на основе заказных разработок, и функций, реализованных на основе стандартных возможностей лицензионного ПО.
Не менее важным, чем выбор инструментальной среды моделирования, является определение этапности приобретения комплекса программного обеспечения для построения модели бизнес-архитектуры, поскольку это оказывает существенное влияние на эффективность инвестиций в ИТ-структуру.
Общим принципом является обеспечение организационно-технологической готовности предприятия к «приему» специализированного программного обеспечения. Данная готовность определяется следующим перечнем условий:
детальный уровень проработки постановок актуальных задач по созданию моделей и установленное соответствие со спецификацией закупок ПО;
соответствие характеристик программно-технической платформы требованиям планируемых к покупке программных средств, поддержки процесса моделирования;
достаточность компетенций технического персонала;
достаточность уровня подготовки пользователей;
проработанность проектных решений в части возможности интеграции инструментальной среды и планируемых к созданию на ее основе моделей в корпоративную информационную систему предприятия.
Своевременность приобретения программных средств с учетом готовности предприятия позволяет обеспечить максимально рациональное использование финансовых средств и таким образом снизить издержки на реализацию проекта.
Основой для выбора наиболее подходящего для предприятия инструментального средства (профиля средств) является знание рынка современных технологий, относящихся к области моделирования. Не претендуя на полноту и детальность, проведем краткий анализ современных средств моделирования.
Источник: megalektsii.ru
