 |
Специализированные алгоритмы анализа (временного, стоимостного) бизнес-процесса с учетом влияния человеческих и технических ресурсов
|
|
|
|
Стандартная конфигурация ARIS предоставляет в распоряжение пользователя очень богатый и функционально полный набор специализированных опций экономического анализа. Это ABC – Activity Based Cost Calculation, Balanced Scoreboard и Simulation. Правда, надо признать, что ожидаемый эффект достигается лишь при условии, что исследуемые модели соответствующим образом подготовлены к анализу. Имеются в виду такие действия, как:
♦ приведение семантики модели в полное соответствие с требованиями методологии ARIS;
♦ удовлетворение условиям по количеству уровней вложенности моделей;
♦ удовлетворение требованиям по числу и типу ассоциаций для функций, присутствующих в моделях;
♦ создание дополнительных сервисных моделей, таких как, например, диаграммы событий, календари смен.
Почти все эти требования могут быть удовлетворены только при помощи «ручных» доводок. При наличии многокомпонентной, многоуровневой модели для, например, симуляции надо, чтобы число ассоциаций функции с другими моделями было единственным. Как правило, неединственная ассоциация является следствием «чувствительности» модели к нескольким условиям, например тип транспорта, тип товара и т. п. Для того чтобы запустить симуляцию на такой модели корректно, необходимо разделить многокомпонентную, многомерную модель на ряд плоских. Каждая их этих плоских моделей реализует «чувствительность» только по одному из параметру или одной группе аналогичных параметров.
Был создан скрипт, при помощи которого на базе многоуровневой модели создавались наборы «плоских» моделей.
Сначала выбирается параметр или группа параметров, определяющая «чувствительность» целевой модели. Затем создается новая целевая группа, куда копируются в автоматическом режиме все модели группы источника.
|
|
|
Далее для всех моделей из целевой группы производится анализ, состоящий в том, что в модели ищутся функции, имеющие более чем одну ассоциацию с моделями типа eEPC. При наличии на модели таких функций из списка ассоциированных моделей исключаются модели, реализующие функционал, отличный от заказанного, например другой транспорт. В списке остается единственная модель, реализующая нужный функционал.
Общесистемный функционал
Равно как и для прикладного функционала, в ряде случаев общесистемный функционал среды ARIS требует дополнительных настроек и доработок, исходя из выбранных постановок целевых задач моделирования и проектных решений по модели. Для удобства последующего изложения материала предлагается следующая систематизация рекомендуемых решений по общесистемному функционалу:
♦ решения по визуализации и настройкам;
♦ проектные решения;
♦ тестирование.
В рамках каждого из выделенных направлений рассмотрим следующие основные решения.
Решения по визуализации и настройкам
ARIS предлагает пользователю свой проводник (ARIS Explorer), дающий возможность доступа ко всем своим возможностям. Если баз в системе много и базы сложны по структуре, то только или разработчик, или высококвалифицированный эксперт сможет быстро сориентироваться в том объеме информации, который представлен на экране. Конечному пользователю, работающему с ограниченным, узко специализированным набором средств, такой объем информации не нужен (рис. 20, 21).
Рис. 20
Рис. 21
Оптимальным можно признать вариант, когда на экране компьютера конечного пользователя находится некая структура, прямо и однозначно связанная с тем функционалом, который этот пользователь выполняет или использует. Эта структура представляет для многих категорий пользователей общую точку доступа к специализированному функционалу, реализованному в моделях специальной базы (рис. 22).
|
|
|
Рис. 22
Разработчики применили для этого концептуально понятный графический образ «домика ARIS», нагрузив его узнаваемые разделы специальным функционалом. Функционал связан с названием раздела – «комнаты» «домика ARIS». Способ доступа прост и применяем в любой модели ARIS – клик мышкой на пирамидке справа внизу от объекта или выбор в окне «Object Windows» на закладке «Assignments».
Задание ролей и определение связи «должность – роль», исходя из штатной структуры подразделения, реализующего бизнес-процесс
Разработчики проекта исходили из того соображения, что конкретная бизнес-функция реализуется не конкретным исполнителем Иванов – Петров – Сидоров, находящимся на конкретной должности, а некоторой организационной единицей, которая в одной организации – техник, в другой – инженер, в третьей – менеджер или еще кто-то. По мнению разработчиков, модель на этапе разработки не должна быть привязана к конкретной штатно-должностной структуре. По этой причине функционал, реализованный в модели, выполняет некую РОЛЬ, с которой может быть связана в последующем любая совокупность исполнителей и штатных структур. Связывание РОЛЬ – ДОЛЖНОСТЬ – ИСПОЛНИТЕЛЬ должно происходить отдельно от модели и никак не влиять на ее (модели) структуру и состав.
Проектные решения
Подключение библиотек настроек организационно-технологической структуры
В соответствии с соглашениями о моделировании в модели используется парадигма (система понятий) – роль. Именно роль выполняет бизнес-функцию, является ее хозяином. Именно роль является элементом окружения практически любой функции (рис. 23).
Рис. 23
Для связывания ролей с должностями и конкретными исполнителями применяется механизм создания организационной модели. Создается модель типа Organization Charts. Элементами ее становятся объекты типа Person Type (роли). Далее создается еще одна модель типа Organization Charts, на ней располагаются иерархически организованные объекты типа Organization Unit (подразделение) и Position (должность) (рис. 24).
|
|
|
Рис. 24
И наконец, последний этап – формируется модель типа Organization Charts, на которой располагаются объект Position (должность) и связанный с ним набор объектов типа Person Type (роль). Мы получаем модель, определяющую зависимость подразделение – его должностной состав, а для каждой должности – ее исполнителя и список обязанностей (ролей), которые исполнитель по решению или кадровых органов, или менеджера по прикладному функционалу должен выполнять.
Еще одним элементом окружения практически любой функции являются информационные системы, средства которых используются для целей автоматизации учета, контроля, информационного взаимодействия и т. п.
Для представления структуры информационных систем применяются модели типа Application System Type, элементами которых являются выстроенные в иерархическом порядке объекты типа Application System Class (класс прикладной системы), Application System Type (прикладная система), классы информационных сервисов, информационные сервисы, ИТ-функции, классы модулей и модули. Пример модели типа Application System Type приведен на рис. 25. Объекты этой модели имеют многоуровневую детализацию – ассоциации, позволяющие в конечном итоге получить подробное представление об информационной среде функции на модели.
Рис. 25
Создание и подключение библиотек специализированных расчетных алгоритмов (модулей) затрат
Стандартная конфигурация ARIS позволяет производить многие виды стоимостных и прочих затратных (время, ресурсы) расчетов. Опции ABC и Simulation рассчитывают минимальные, максимальные и средние значения затрат многих видов ресурсов. Как уже упоминалось, для того чтобы получить коррелированные данные, надо долго и тщательно готовить модели. Получаемые отчеты очень подробны, содержат много ценной информации, но чтобы из нее выделить нужное, требуется дополнительная обработка отчетов при помощи дополнительных инструментов – как правило, статистического анализа. Однако далеко не всегда пользователь располагает знанием, временем, навыками, необходимыми для выполнения всего комплекса подготовительных и прочих мероприятий. Часто пользователей или интересуют очень специальные данные, которые нерационально долго извлекать, пользуясь стандартным вычислительным аппаратом, или данные выдаются не в том разрезе, который нужен. Для решения узких, специальных задач более рациональным может оказаться создание специализированных расчетных модулей, дающих результат много быстрее и с меньшими издержками. Например, создан скрипт, который выполняет:
|
|
|
♦ присвоение значений некоторым атрибутам функций типа Times и Cost (максимальные, минимальные или средние значения соответствующих затрат);
♦ присвоение значений некоторым атрибутам типа Free attributes (специальные расчетные параметры, отсутствующие в стандартной поставке, но интересные для прикладного применения);
♦ присвоение значений некоторым атрибутам связей между функциями, оргединицами и информационными системами (число работников, процент использования – загрузка различных ресурсов).
Запуск прохождения по модели с указанными атрибутами и расчет с выдачей протокола затрат времени, средств по пройденному «маршруту»
Пример кода, реализующего некоторые из этих действий, приведен в приложении 2. Это функции Function secs (ss As Variant) As Long, Function time_count (sss As Double) As String и процедура Sub Count.
Также создан скрипт, выполняющий расчет зависимости затрат времени и денежных средств от загрузки средств информационной системы при прохождении по специфицированному «маршруту». Будучи выведенным в формате Excel, отчет позволяет получить диаграммы, наглядно показывающие тенденции в использовании тех и или иных информационных систем в бизне^процессах.
Связь между моделью «как есть» и «как должно быть» (независимая база, варианты)
Цели модернизации, актуализации базы, оптимизации процессов предполагают действия по изменению структуры базы, составляющих ее моделей, связанных с моделями объектов и т. п. Базу моделей из состояния «как есть» стремятся перевести в состояние «как будет», «как должно быть» – путем оптимизации процессов по структуре, времени выполнения, порядку распределения ресурсов и т. д. Этого эффекта достигают путем введения дополнительных типов ресурсов, информационных систем и т. п. Оптимизации осуществляются путем применения модуля Simulation. Изменения моделей проводятся, как правило, путем создания копий моделей и последующих их (моделей) модификаций. Копирование моделей производится или вручную, или через механизм «вариантов». Для сохранения унаследованных от моделей-источников связей применяют копирование или «варианты» через использование occurrences моделей и объектов на них. Это сохраняет унаследованные связи. Правда, сразу возникает проблема – изменение объектов модели-приемника сразу же изменяет и модель-источник, что далеко не всегда устраивает разработчика. Приходится копировать модели как Copy
|
|
|
Definitions, это позволяет вносить изменения, не затрагивая модель-источник, но в этом случае – новая проблема – теряются связи объектов. Приходится их восстанавливать вручную, что требует много времени, внимания и чревато ошибками. Были разработаны скрипты, в автоматическом режиме выполняющие функционал копирования моделей с сохранением, где надо, связей.
Один из скриптов уже описан в разделе «Сохранение маршрута модели в виде отдельной модели, связанной с общей базой модели бизнес-архитектуры».
Как известно, Simulation при выполнении может проанализировать только те функции, которые имеют одну и только одну ассоциацию с моделью типа eEpc. Если ассоциаций больше, то процесс Simulation «зависает». Был разработан скрипт, который так корректирует структуру модели, что она (модель) удаляет лишние не нужные для бизнес-процесса связи, сохраняет связи с нужными для бизнес-процесса моделями и источниками данных. Этот скрипт применяется к группе, копируя в целевую группу все модели группы-источника, и дополнительно выполняет следующий функционал:
♦ в диалоговом режиме запрашивает параметр, определяющий «чувствительность» целевых моделей, например тип транспорта;
♦ в автоматическом режиме копирует модели группы как Copy Occurrences;
♦ в цикле для каждой модели проверяет наличие на ней функций, имеющих ассоциации с eEPC-моделями, чувствительными по выбранному параметру, например по типу транспорта;
♦ при наличии таких функций:
– создается новое definition (определение) функции;
– атрибуты новой функции делаются такими же, как у функции-источника;
– из списка ассоциаций новой функции удаляются ссылки на модели, не удовлетворяющие выбранному параметру (остается только ссылка на модель, имеющая атрибут чувствительности по транспорту, равный выбранному);
– создается новое occurrence (представление) новой функции;
– создаются новые occurrences (представления) связей между occurrence (представлением) новой функции и occurrences (представлениями) объектов, составляющих окружение функции-источника;
– удаляется «старое» occurrence функции на модели.
В итоге автоматически, быстро, очень корректно и безошибочно получаем группу моделей, сохранивших связи с моделями, независимыми от, например, транспорта.
Такие группы моделей после соответствующей подготовки (назначения вероятностей событиям или формирования диаграмм событий, формирования дополнительных моделей, например графиков смен) можно оптимизировать Simulation или анализировать другими стандартными средствами ARIS (ABC или Balanced Scoreboard).
Формирование чувствительности документов
Документы в любом виде – печатном или электронном – представляют собой или элементы нормативной системы, придающей бизнес-процессам легитимность, или элементы оперативной среды, обеспечивающие процедурную, смысловую поддержку бизнес-процессов. Группирование документов на нормативные и оперативные – логичная и повсеместно применяемая практика моделирования бизнес-процессов. Часто бывает оправданной или даже необходимой дальнейшая, более подробная группировка. Например, нормативные документы делятся на законы, приказы, кодексы, распоряжения и т. д., а оперативные – на коммерческие, государственные, ведомственные и т. д. Кроме того, в зависимости от особенностей протекания бизнес-процессов документы должны группироваться по многим другим признакам. Таким образом, становится актуальной проблема – сделать документы «чувствительными» к режимам функционирования, к особенностям протекания бизнес-процессов.
Чтобы сделать документы «чувствительными» к режимам функционирования бизнес-процессов, применяется механизм назначения определенным атрибутам документов специальных значений, закрепленных в Соглашении о моделировании.
Например, значение атрибута документа Ident i fier= «DOC_NP_*» «делает» документ нормативным, а «DOC_OP_*» – оперативным. Добавление постфикса вместо символа «*» позволяет ввести дополнительную градацию. Например, «PSM» – это письма, а «LAW» – законы и т. д. На рис. 26, 27 приведены примеры применения такой практики к документам.
Рис. 26
Рис. 27
Для задания чувствительности документов к, например, типу товара, некоему режиму и типу транспорта происходит присвоение атрибутам документа «User attribute Text 1», «User attribute Text 2» и «User attribute Text 3» специальных значений, определенных в «Соглашении о моделировании» в соответствующей, также согласованной нотации. Пример применения этих соглашений приведен на рис. 28.
Рис. 28
В процессе работы специально разработанных скриптов происходит анализ атрибутов документов из окружения функции, и, если совокупность атрибутов документа соответствует совокупности атрибутов, определяемых при выборе входных параметров скрипта (тип товара, таможенный режим, тип транспорта), документ помечается цветом при проходе по модели и его название помещается в выходной отчет.
Тестирование
Создаваемые в процессе моделирования диаграммы должны удовлетворять спецификациям ARIS по структуре, синтаксису, другим согласованным требованиям. Соответствие этим требованиям проверяется при помощи скриптов семантического анализа среды ARIS. Нужно признать, что разработчики часто отходят от соглашений ARIS, создавая диаграммы в соответствии со своими «Соглашениями о моделировании». В этом случае семантическая проверка ARIS применяется в ограниченном режиме. Проблемы же корректности моделей решаются путем написания и запуска на моделях тестирующих скриптов, учитывающих особенности «своих» «Соглашений о моделировании».
Например, при потоковом тестировании моделей при формировании помеченного «маршрута» применялись генераторы случайных чисел, с помощью которых формировались случайные условия на входе и случайные условия в процессе формирования «маршрута».
Формирование случайных сочетаний параметров входных условий
При формировании входных параметров использовались случайным образом выбранные тип товара, некий режим, тип транспорта. В приложении 2 приведен пример кода, формирующего случайным образом тип транспорта. Это Function seltransrand() As String.
Формирование случайных сочетаний принимаемых бизнес-решений
Описание механизма формирования на модели точек принятия бизнес-решений подробно дано в разделе «Интерактивный режим прохождения в реальном масштабе времени бизнес-процесса с учетом заданных параметров входных условий и принятия бизнес-решений». Механизм формирования случайных наборов бизнес-решений использует точки принятия решений, описанные выше. Но в отличие от интерактивного режима, заменяет интерактив применением случайного сгенерированного числа, как индекса в массиве альтернатив выбора бизнес-решения.
Потоковое тестирование и анализ модели на основе случайно заданных параметров входных условий и чисел
Потоковое тестирование применено для практически безынтерактивного циклического обхода моделей с пометкой пройденного маршрута и генерацией отчета о сделанных выборах – входных параметрах в начале каждого цикла и выбранных бизнес-решениях – в промежуточных точках принятия решений. Скрипт, реализующий данный функционал, в цикле производил случайные выборы и использовал их при формировании случайного «маршрута».
Специализированные проверки составных элементов модели
Иногда нет необходимости проводить анализ всей модели. Часто нужно проанализировать свойства одного или нескольких объектов разного типа на модели или его связи (входящие и исходящие). Для этого применялась система небольших скриптов, запускаемых на объектах и выполняющих только очень узкий специализированный функционал.
Интеграционные решения
Специфика постановок задач и реализующих их проектных решений в ряде случаев не может быть эффективно учтена в рамках использования стандартных возможностей ARIS либо «авторских» доработок исполнителя. Принципиально среда ARIS позволяет обеспечить соответствующую интеграцию с другими средствами моделирования и широко распространенными технологиями в части:
♦ форматов загрузки, выгрузки информации;
♦ использования специализированного функционала.
Стандартно ARIS предоставляет средства взаимодействия с другими CASE-средствами разработки и поддержки моделирования бизнес-процессов. Назначение этих средств – обмен отдельными моделями с другими программными CASE -системами посредством файлов, записанных в XML-кодах. Этот обмен осуществляется при помощи специальных программ-интерфейсов сторонних производителей, например компании Reischmann Informatik GmbH (RI) (www.reischmann.com). В настоящее время интерфейсы TOOLBUS компании RI поддерживают больше чем 30 инструментальных CASE -средств. Посредством этих интерфейсов можно произвести обмен данными между ARIS и такими CASE-си-стемами, как ErWin от СА, PowerDesigner от Sybase и OracleDesigner. Обмен может быть произведен в обоих направлениях.
На взгляд авторов, одним из перспективных направлений по интеграции возможностей ARIS с «внешними» технологиями может быть наработка постановок задач и поддерживающих их проектных решений применительно к MSProject.
Одной из имеющих «право на жизнь» постановок задач в рамках моделирования бизнес-процессов предприятия является анализ загрузки кадровых ресурсов. MSProject в силу приоритетности данной задачи для управления проектами имеет очень развитую функциональность в части контроля и отображения всех процессов, связанных с использованием ресурсов.
В частности, данным средством поддерживаются такие полезные функции, как расчет оптимальной загрузки персонала при выполнении проектов, диалоговый режим формирования условий оптимизации загрузки персонала, быстрое формирование стандартных отчетов и некоторые другие.
Поэтому целесообразной видится реализация следующей технологической схемы совместного использования ARIS и MSProject:
♦ из ARIS «выгрузить» в формате Excel информацию по ресурсам для MSProject;
♦ загрузить в MSProject информацию по ресурсам в формате Excel;
♦ в MSProject в рамках использования стандартного функционала получить требуемую информацию (результаты) по контролю и анализу загрузки ресурсов;
♦ преобразовать результаты, полученные в MSProject, в форматы, совместимые с ARIS (как правило, это формат Excel);
♦ загрузить результаты в формат Excel в разработанную модель ARIS с последующим подключением к соответствующему функционалу, предоставляемому комплексной моделью.
Специально разработанные модули, которые могут поддержать данную технологическую схему, могут быть следующего вида:
♦ скрипт выполняет формирования в формате Excel четырех рабочих листов специальной структуры, «понятной» программе-приемнику. Для формирования 1-го листа скрипт «проходит» по модели, формируя для каждой посещенной функции данные в следующем формате – «ID», «Функция», «Длительность», «Предшественник», «Уровень структуры». На 2-м листе должны формироваться данные по исполнителям. На 3-м листе должны формироваться данные по загрузке исполнителей. На 4-листе должна присутствовать идентификационная информация MSProject. Она формируется предварительно и добавляется в выходной файл, созданный скриптом «вручную»;
♦ ассоциированные модели преобразуются в «вехи» MSProject (веха не имеет длительности и ресурсов).
В рамках аналогичного подхода (предложенной технологической схемы) могут быть реализованы задачи по временной и стоимостной оценке бизнес-процессов с использованием функциональных возможностей MSProject, а именно:
♦ определение критического пути;
♦ выработка рекомендаций по оптимизации загрузки персонала.
Достаточно интересным может быть интеграционное решение, которое, в отличие от вышерассмотренного случая, направлено не на дополнение функциональных возможностей ARIS за счет MSProject, а наоборот – на использование ARIS для решения целевых задач MSProject.
Заключение
Общая задача, которая ставилась авторским коллективом перед написанием книги, – аргументированно показать, с одной стороны, актуальность и эффективность внедрения механизмов описания бизнес-процессов в деятельность организации в современных условиях, а с другой – сложность процесса построения действительно полезных для практики бизнес-моделей.
Достаточно затруднительно дать собственную оценку того, насколько убедительна была аргументация необходимости и неизбежности вхождения моделирования бизнес-архитектуры в «культуру управления» предприятий, стремящихся максимально соответствовать современным международным стандартам. Вместе с тем хотелось бы отметить тот факт, что за период работы над книгой члены авторского коллектива неоднократно привлекались к исполнению нескольких проектов по бизнес-моделированию со стороны различных государственных и коммерческих структур. Кроме того, состоялось большое количество контактов с заинтересованными заказчиками, которые в силу текущих организационных и финансовых ограничений не смогли обеспечить старт проекта в текущем периоде.
Особо следует отметить, что данные события были не только «спровоцированы» активностями потенциальных исполнителей по ознакомлению с возможностями и ожидаемыми результатами по разработке бизнес-моделей по внедрению в деятельность организации, но и имели независимые причины, обусловленные повышенным интересом рынка к данному виду услуг.
В той же мере авторскому коллективу затруднительно оценить, насколько полно нашла отражение в книге сложность процесса построения реально востребованных бизнес-моделей. Так или иначе, в заключение хотелось бы еще раз подчеркнуть организационную и технологическую проблематику создания моделей.
Можно взять на себя смелость утверждать, что из всех консалтинговых проектов, в том числе ИТ-направления, бизнес-моделирование является лидером по таким параметрам, как:
♦ значительное количество разнородных специалистов, роль каждого из которых имеет критичное значение для успеха проекта: юристы, производственные технологи, кадровые сотрудники, ИТ-специалисты и т. д.;
♦ обширный состав заинтересованных подразделений заказчика, которые являются потенциальными пользователями системы;
♦ необходимость поддержки в актуальном состоянии разработанной бизнес-архитектуры.
По этой причине организационные проблемы, включающие подбор компетенций, распределений ролей по проекту, планирование активностей, то есть управление проектом, во многих случаях могут стать основной причиной неудач и снивелировать высокие технологические возможности недостаточно подготовленного в организационном аспекте исполнителя.
В этой же плоскости организационных проблем лежит и четкая постановка задач, увязанная с готовностью заинтересованных подразделений заказчика обеспечить синхронную работу по проекту.
Технологическая проблематика связана с тем, что далеко не всегда декларируемые производителями возможности инструментальных средств могут быть реализованы на практике. Как правило, работы по каждому конкретному проекту требуют учета специфических условий и требований заказчика: постановок задач, реализации функционала, интеграции (взаимодействия) с информационными системами и т. д. По совокупности воздействия этих факторов исполнитель сталкивается с необходимостью «ручной» доработки используемой инструментальной базы, задействования и интеграции в общее решение других инструментальных средств, в которых тот или иной функционал реализуется более эффективно.
По этой причине предложенные в книге в виде организационно-технологических решений (рекомендаций) варианты обхода препятствий и «подводных камней», обусловленных объективно существующими ограничениями у используемой инструментальной среды, могут использоваться для сдвига с «мертвой» точки технологических проблем по проектам.
Следует отметить, что многие из представленных рекомендательных положений были выработаны авторским коллективом в результате практического исполнения масштабных работ по моделированию бизнес-процессов, и в этом смысле можно говорить о реальной их апробации.
На текущий момент «многопрофильность» проблематики построения формализованных бизнес-моделей не встречает адекватной готовности среды исполнения и внедрения.
Заказчики не знают в полной мере всех возможностей современных инструментальных средств моделирования, методологии использования моделей в практике управления развитием, потенциальных эффектов от внедрения бизнес-моделей в практику деятельности организации, условий для полномасштабного внедрения, особенностей поддержки процесса использования и т. д.
Исполнители зачастую по разным причинам позиционируются на использовании ограниченного функционала инструментальных средств моделирования, избегают решений, связанных с комплексированием различных взаимодополняющих по функционалу инструментальных средств, не в полной мере укомплектовывают исполнителей специалистами с разными компетенциями.
Дистрибьюторы инструментальных средств, позиционируясь на текущую недостаточно высокую эффективность их использования, не обеспечивают качественного уровня технической поддержки, не создают углубленных курсов обучения для опытных специалистов.
Отсутствие должного уровня консолидации основных участников, обеспечивающих формирование культуры и практики использования бизнес-моделирования в различных областях, является одной из главных причин, тормозящих процесс широкого распространения технологий управления на основе моделирования.
В этом смысле книга, ориентируясь на общий целевой результат, рассматривала проблематику разработки бизнес-моделей с разных позиций и участников процесса. Очевидно, что в такой постановке уже можно ожидать взаимопротиворечащих оценок относительно изложенных решений, поскольку существует определенная конфликтность интересов исполнителя, заказчика, дистрибьютора инструментальных средств.
Хочется отметить позицию авторского коллектива в отношении оценки перспектив развития инструментальных и методологических средств бизнес-моделирования.
В ближайшем времени следует ожидать существенного изменения роли и места инструментальных средств моделирования в общей системе организационно-технологического управления предприятием. Современный уровень функциональных возможностей инструментальных средств моделирования позволяет перейти от «пассивной» – описательной роли к «активной» – прикладной роли в качестве составного элемента систем автоматизированного управления.
Можно выделить в качестве основных следующие направления прикладного использования инструментальных средств моделирования:
♦ управление логикой взаимодействия автоматизированных информационных систем (АИС) в рамках информационно-технологической поддержки управления бизнес-процессом;
♦ организация экспертно-консультационной поддержки персонала в рамках непосредственного участия в бизнес-процессе;
♦ обеспечение протоколирования (в том числе юридически значимого) действия участников бизнес-процессов в ходе его исполнения.
Перечисленные направления реализуются на основе «комплексирования» ключевых возможностей современных инструментальных средств:
♦ обеспечение практически неограниченного уровня детализации формализованного описания бизнес-процессов (с охватом всем основных компонент – информационной, технологической, организационной);
♦ обеспечение интерактивных режимов взаимодействия с пользователями и «внешними» информационными системами.
Несомненно, что только за счет своих собственных технологических возможностей вышеперечисленные перспективные направления использования навряд ли могут быть реализованы. Очевидно, что потребуется разработка специализированных интегральных решений, в рамках которых будет осуществлено «дополнение» недостающих возможностей инструментальной среды моделирования.
Весьма интересной видится перспектива поиска интеграционных решений совместного использования современных систем управления информационными системами и инструментальных средств моделирования. На этом направлении можно ожидать появления новых проектов и изданий, касающихся новых сфер применения инструментария и методологии бизнес-моделирования.
Вполне вероятен и такой вариант развития событий, когда будет происходить совершенствование инструментальных средств моделирования в интересах обеспечения более высокой готовности к реализации вышеописанной «активной» деятельности предприятия.
В завершение хотелось бы выразить надежду, что даже при возможной неоднозначной оценке тех или иных положений книги общая реакция аудитории будет направлена на положительное понимание значимости, а главное, реализуемости в обозримой перспективе широких возможностей современных инструментальных и методологических средств для построения и использования формализованных бизнес-моделей в управлении деятельностью организации.
Приложения
Приложение 1
Основные термины и определения
Приложение 2
Примеры прикладного кода на Sax Basic
Приложение 3
Типовое техническое задание на разработку модели бизнес-архитектуры
Введение
Реализация проекта по оптимизации бизнес-процессов позволит полностью проанализировать все ключевые бизнес-процессы организации, выявить процессы, негативно влияющие на функционирование организации, и обеспечить их соответствующую модернизацию. Переработанные в результате выполнения проекта бизнес-процессы обеспечат сохранение и повышение качественных и количественных показателей функционирования организации с учетом растущей конкуренции и развивающихся технологий.
Название и назначение
Название
Полное название проекта: «Оптимизация и разработка бизнес-процессов организации».
Назначение
Назначением настоящей работы являются формализация и описание процедур, действий, документооборота и информационного взаимодействия, происходящего в организации при выполнении ее бизнес-задач. Результаты данной работы будут являться основой для стандартизации выполнения процедур и действий сотрудниками организации в процессе ее функционирования.
Цель и задачи
Целью настоящего технического задания является обеспечение условий для развития бизнеса организации, а также минимизации временных и материальных затрат, связанных с ее функционированием.
Для достижения поставленной цели должны быть решены следующие задачи.
1. Построение полнофункциональных моделей процедур функционирования организации с использованием инструментальных средств описания моделей бизнес-процессов как есть и как должно быть в случае их оптимизации.
2. Внедрение основанного на применении инструментальных средств описания моделей бизнес-процессов механизма разработки технологических схем, инструкций для сотрудников организации, а также описания проектов (экспериментов), направленных на оптимизацию выполнения процедур функционирования организации.
3. Обеспечение условий для разработки методологического и информационного обеспечения бизнес-процессов организации, в том числе в целях создания и внедрения информационной составляющей в бизнес-процессы.
Ожидаемый эффект
В результате выполнения работ ожидается обеспечить:
♦ систематизацию знаний об организации выполнения бизнес-процессов;
♦ систематизацию знаний о принципах автоматизации бизнес-процессов, с учетом в том числе мировой практики;
♦ системный и аргументированный подход к формализации бизнес-процессов организации;
♦ механизм оптимизации и разработки бизнес-технологий;
♦ условия для оптимизации бизнес-процессов организации, а также их автоматизации;
♦ механизм разработки технологических схем, инструкци
|
|
|
