Для поддержки этого сложного процесса применяют различные инструменты моделирования и управления архитектурой предприятия.

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

Archi – это свободно распространяемый межплатформенный инструмент с открытым кодом для моделирования на всех уровнях архитектуры предприятия в терминах языка ArchiMate. Archi разработан и является зарегистрированной торговой маркой Филиппа Бовуара (Phillip Beauvoir). Программный продукт Archi создан на основе фреймворка Eclipse Rich Client Platform (RCP) с использованием интегрированной среды разработки Eclipse IDE. Текущая версия программного продукта Archi 3 выпущена 29.09.2014 и доступна для скачивания с сайта производителя [1, 2]. В Archi 3 встроены два демонстрационных примера моделей архитектуры предприятия. После установки программного продукта они размещаются в папке Examples.

Основа инструмента Archi – это ArchiMate. ArchiMate – стандарт языка моделирования архитектуры предприятия с открытым исходным кодом, разрабатываемый консорциумом Open Group. Язык ArchiMate поддерживается инструментальными средствами различных вендоров и активно применяется консалтинговыми компаниями [3]. Он полностью согласован с моделью архитектуры предприятия TOGAF, также поддерживаемой консорциумом Open Group [4]. ArchiMate поддерживает описание, анализ и визуализацию архитектуры предприятия.

Согласно требованиям языка ArchiMate модель архитектуры предприятия в Archi определена для трех основных уровней: уровня бизнеса (Business layer), уровня приложения (Application layer) и уровня технологий (Technology layer), и двух дополнительных уровнях, называемых расширениями.

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

Уровень приложения поддерживает уровень бизнеса с помощью прикладных сервисов, которые реализуются программными приложениями. Уровень приложения в Archi может быть представлен 7 элементами.

Уровень технологий представляет инфраструктуру (серверы, узлы, сети и т.д.), необходимую для работы приложений. Уровень технологий в Archi может быть представлен 9 элементами.

Кроме трех уровней архитектуры предприятия в версии языка Archimedes 2 были добавлены понятия/расширения Motivation (мотивация), Implementation &Migration (реализация и миграция). Для представления мотивации Archi предлагает 7 элементов, для представления второго расширения Archi предлагает 4 элемента. Каждый элемент модели может быть связан с одним или более других элементов. Связи между элементами архитектуры в Archi могут быть представлены с помощью 13 типов отношений. Для визуализации элементов архитектуры предприятия на диаграммах (View) Archi предоставляет палитру элементов, сгруппированных по типам.

Рабочее пространство в Archi разделено на 8 окон:

- главное окно для отображения и редактирования диаграмм;

- Models, или «Дерево моделей», отображает все открытые модели;

- Properties показывает свойства выбранного элемента модели;

- Outline отображает содержимое ArchiMate-диаграмм в миниатюре, полезен для навигации по большим диаграммам;

- Navigator показывает выбранные элементы модели и все их связи с другими элементами модели; используется для навигации между связанными элементами через их связи;

- Palette представляет набор графических образов элементов ArchiMate-диаграмм;

- Visualiser показывает выбранные элементы модели и все их связи с другими элементами модели в графическом виде, является графическим эквивалентом окна Navigator;

- Hints содержит текстовую подсказку для типа объекта, выбранного в окнах Models или Palette.

С помощью техники «drag & drop» можно настроить произвольное размещение окон, в том числе форме закладок в других окнах.

Archi полностью поддерживает возможности Undo/Redo. Отмена и повтор команд в Archi является контекстно зависимой опцией. Она применяется к модели, которая выбрана либо в Дереве моделей, либо в окне диаграмм.

Ряд процедур в процессе моделирования архитектуры предприятия в Archi обеспечено специальными подсказками (Cheat sheets, шпаргалками), которые представляют собой пошаговые интерактивные инструкции. Подсказки доступны из меню Help в главном меню. В версии 3 имеется две встроенные подсказки: «Create a Map View» и «Create a New Model». По мере появления новых пошаговых интерактивных инструкций, их можно подгружать в Arhi. Предполагается, что со временем все процедуры процесса моделирования архитектуры в Archi будут обеспечены соответствующими пошаговыми интерактивными инструкциями.

Модель архитектуры предприятия в Archi отображается в форме древовидной структуры (Model Tree, Дерево модели) элементов, сгруппированных в папки, представленной на рисунке 1 и в таблице 1.

Рисунок 1 – Структура папок верхнего уровня модели архитектуры в Archi

Таблица 1 – Назначение папок верхнего уровня в Archi

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

Элементы можно добавлять из Дерева моделей на любое количество диаграмм с помощью техники «drag & drop». Элементы Дерева моделей, используемые на диаграммах, автоматически выделяются курсивом. Это позволяет визуально найти в Дереве моделей устаревшие элементы, которые можно удалить.

Кроме того, Archi позволяет:

- синхронизировать выделения (Synchronising Selections) элементов в дереве моделей и на диаграмме;

- выполнять поиск и фильтрацию элементов в Дереве моделей;

- найти и заменить элемент в Дереве моделей;

Элементы созданной модели архитектуры предприятия и связи между ними в Archi могут быть представлены графически с помощью одного или нескольких представлений (View). Например, можно создать одно графическое представление для бизнес-уровня, второе – для уровня приложений и т.д. Кроме того Archi поддерживает автоматическое создание Главного представления (“master” View), которое служит своеобразным оглавлением, или картой, (map) для всех остальных представлений в модели.

Согласно спецификации ArchiMate [3] архитекторы и другие заинтересованные стороны (stakeholders) могут создавать собственные представления архитектуры предприятия. Archi позволяет определять точки зрения (Viewpoints). В Archi точка зрения представляет подмножество элементов и отношений между ними. Инструмент поддерживает 26 точек зрения. При создании нового представления по умолчанию установлена точка зрения Total, разрешающая добавлять на диаграмму любые элементы из любых уровней архитектуры. Если изменить точку зрения Total на другую, то «запрещенные» для выбранной точки зрения элементы и отношения на диаграмме и в окне Дерево моделей станут бледными, кроме того станут недоступными соответствующие элементы в Палитре элементов.

Для генерации отчетов Archi использует специализированное средство Jasper Reports, Archi может экспортировать созданные модели архитектуры предприятия в различные форматы: HTML, RTF, PPTX, PDF, DOCX, ODT, используя шаблоны Jasper Reports. В режиме моделирования Archi позволяет распечатать лишь открытую диаграмму.

Среди достоинств Archi можно выделить следующие:

• бесплатный;
• можно создавать модели на русском языке;
• можно русифицировать меню [5];
• межплатформенный;
• с открытым исходным кодом;
• поддерживает стандарт языка моделирования архитектуры предприятия ArchiMate;
• позволяет отслеживать связи между элементами модели архитектуры;
• со встроенной контекстной подсказкой по типам элементов архитектуры;
• встроенные примеры моделей архитектуры предприятия;
• пошаговые интерактивные инструкции;
• легкий для понимания.

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

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

Благодаря выше перечисленным достоинствам Archi быстро набирает популярность в различных областях бизнеса и образования.

К недостаткам инструмента можно отнести следующие:

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

Таким образом анализ возможностей программного продукта Archi версии 3, а также источников [1-7] позволяет сделать следующий вывод. Инструмент нацелен, в первую очередь, на тех, кто делает первые шаги в моделировании на языке ArchiMate и ищет бесплатное межплатформенное средство моделирования на языке ArchiMate, поддерживающее признанные модели архитектуры предприятия, в частности модель TOGAF.

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

Согласно учебному плану подготовки бакалавров по направлению 080500.62 «Бизнес-информатика» заочной формы обучения в Финансовом университете студенты должны выполнить учебный проект по бизнес-инжинирингу. Данный учебный проект является одной из форм аудиторной и внеаудиторной самостоятельной работы студентов [2].

Основными целями учебного проекта по бизнес-инжинирингу являются

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

- отработка навыков командной работы;

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

При выполнении учебного проекта используются знания и навыки следующих предшествующих дисциплин [2]: «Моделирование бизнес-процессов», «Архитектура предприятия», «Управление жизненным циклом ИС», «Информационные системы управления производственной компанией», «Базы данных», «Архитектура корпоративных информационных систем», «Методология и технологии проектирования информационных систем», «Программная инженерия», «Управление ИТ-проектом», «Экономика информационных систем».

В качестве инструментальных средств для поддержки этапов учебного преокта по бизнес-инжинирингу рекомендуются программные продукты, которые студенты освоили в ходе изучения предшествующих дисциплин: MS Word, MS Excel, MS Visio, MS Project, CA ERwin Process Modeler, ARIS Business Architect, ARIS Express, Star UML, BizAgi Process Modeler, Archi.

Учебный проект выполняется командой студентов.

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

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

По результатам выполненной работы команда студентов оформляет единый отчет, включающий следующие структурные элементы согласно [3]: титульный лист; список исполнителей; задание; содержание; введение; основная часть; заключение; список использованных источников; приложения.

Оформление страниц отчета «Титульный лист», «Список исполнителей», «Задание» производится согласно требованиям кафедры «Бизнес-информатика».

Задание содержит описание бизнес-кейса, включая краткое описание бизнеса, формулировку бизнес-проблемы, а также постановку задачи инжиниринга.

Структурный элемент отчета Содержание включает введение, наименование всех разделов, подразделов, пунктов (если они имеют наименование), заключение, список использованных источников и наименование приложений с указанием номеров страниц, с которых начинаются эти элементы работы. Содержание должно быть создано автоматически с помощью инструмента «Оглавление» в MS Word. Содержание начинается на странице с номером «4».

Отчет команды по практикуму должен быть представлен в едином файле.  Общий объем отчета составляет 50-60 страниц, включая таблицы, рисунки.

Задание на проектный практикум студенты получают на первом практическом занятии. Задание выполняется в течение учебного семестра самостоятельно командой студентов. Единый отчет по практикуму, выполненный командой студентов, передается преподавателю в электронном виде на электронный адрес преподавателя. По итогам проверки преподаватель может высказать замечания, которые должны быть учтены в окончательной версии отчета по контрольным работам. Окончательная версия отчета должна быть представлена преподавателю как в электронном, так и в печатном виде. На титульном листе отчета должны присутствовать подписи всех участников команды.

Итоговая электронная версия отчета должна включать: файл отчета по контрольным работам, файлы всех разработанных моделей, шаблонов и отчетов. Все файлы должны быть собраны в одну папку и архивированы. Название папки должно включать номер группы и фамилии студентов.

Этапы выполнения учебного проекта по бизнес-инжинирингу

1. Сформировать проектную команду. Выбрать руководителя команды учебного проекта [2].

2. Выбрать тему учебного проекта. Дать краткую характеристику объекта инжиниринга: выбранной компании и выбранных проблем в деятельности компании. Сформулировать задание на бизнес-инжиниринг [2, 4].

3. Спланировать проект по бизнес-инжинирингу с помощью специализированных программных средств, например, MS Project [2, 5, 6].

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

4. Сформировать образ будущего компании согласно Заданию [2, 7].

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

5. Разработать комплексную модель «AS IS» деятельности компании, провести анализ деятельности компании на основе разработанных моделей [2, 7, 8, 9].

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

Разработка разных аспектов и уровней комплексной модели компании выполняется на основе знаний и навыков, полученных в результате изучения предшествующих дисциплин учебного плана с помощью программных продуктов, освоенных в процессе изучения предшествующих дисциплин, например, CA ERwin Process Modeler, ARIS Business Architect, ARIS Express, Star UML, BizAgi Process Modeler, Archi.

6. Разработать предложения по инжинирингу компании [2, 4, 6].

Результатом этапа является краткое текстовое описание предлагаемых вариантов инжиниринга.

7. Для каждого варианта инжиниринга разработать комплексную модель «TO BE». Данный этап выполняется аналогично этапу 5.

8. Сформировать список критериев для выбора лучшего варианта бизнес-инжиниринга [4, 7].

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

10. Сформулировать требования к ИС поддержки выбранного варианта инжиниринга компании [10, 11].

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

11. Провести план/фактный анализ выполненного учебного проекта по бизнес-инжинирингу, используя специализированные средства, например, MS Project [2, 5]

12. Подготовить Заключение по учебному проекту.

13. Оформить единые отчет команды студентов по учебному проекту согласно требованиям кафедры.

14. Отправить преподавателю электронную версию единого отчета для проверки.

15. Внести исправления, если таковые получены от преподавателя.

16. Распечатать отчет, подписать титульный лист, сшить отчет. Сформировать электронный архив материалов по проекту, отправить архив преподавателю.

Оценивание результатов учебного проекта осуществляется с учетом следующих групп критериев:

- роли (ролей) каждого участника команды в проекте, а также фактической части работы, выполненной каждым участником, указанной в отчете по в разделе «Список исполнителей»;

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

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

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

Сегодня перед руководителями организаций остро стоит вопрос выбора эффективной стратегии управления проектами. Проектно-ориентированный подход, как правило, используется в компаниях, специфика работы которых предполагает уникальную или близкую к данному понятию деятельность. Под понятием уникальной деятельности подразумевается ориентированность стратегии организации на создание некоторых принципиально новых услуг либо на добавление элементов новизны в уже существующие. Очевидно, что в условиях стремительного развития технологий сложно себе представить создание новых услуг без использования возможностей информационных технологий. Проекты по созданию новых услуг с применением современных технологий требуют высокой эффективности бизнес-процессов, так как цена ошибок и неэффективных решений может быть очень велика. В условиях жесткой конкуренции на рынке неэффективное управление может серьёзно снизить конкурентоспособность организации. Например, компания A первой начала разработку нового сервиса бесконтактной оплаты банковскими картами. На момент начала разработки у компании не было конкурентов, и данная ниша рынка была бы для них свободна. При этом, существуют ещё компании B и C, с более скромными ресурсами, но с сильным желанием реализовать такой же сервис. Данная ситуация – не редкость на рынке. Часто случается, что у нескольких компаний конкурентов появляются похожие идеи новых сервисов. Очевидно, что та компания, которая быстрее и качественнее реализует данный сервис, будет в более выигрышном положении. Конечно, существует множество ограничений и допущений, но в целом выход на открытый рынок первым позволяет получить конкурентное преимущество. Данный пример демонстрирует актуальность и важность проблемы эффективности управления ИТ-проектами. Если, например, лица, принимающие решения в компаниях A и C, приняли неэффективные решения, то у компании B появляется возможность первой сделать релиз нового сервиса и, соответственно, получить необходимое конкурентное преимущество. Неэффективными решениями в данном случае можно считать: неэффективное выделение и распределение ресурсов, неэффективное планирование, неэффективная организация работы в проектных группах, неэффективные методы проектирования, разработки, тестирования. Проблема принятия неэффективных управленческих решений сегодня является одним из ключевых факторов, снижающих будущий экономический эффект от запускаемых ИТ-проектов, что делает данную проблему действительно актуальной.

Согласно отчету, представленному аналитической компанией Research [1], в 2014 г. 77% компаний использовали специализированное программное обеспечение (ПО) для управления проектами. Согласно данному исследованию, основными бизнес задачами, решаемыми с помощью подобных программных систем, являются сокращение временных и финансовых затрат, централизация всей информации о проекте в одном месте, сокращение количества бумажной документации, повышение четкости и прозрачности процессов. Данные системы получают высокие оценки от пользователей и успешно применяются как в сложных и дорогостоящих, так и в небольших локальных проектах. Однако, стоит заметить, что часто подобные системы используются далеко не на максимум своих возможностей, а многие из них в принципе имеют не слишком разнообразный функционал. Большинство подобных систем универсальны и могут применяться во многих сферах бизнеса, реализуя основные потребности проектных менеджеров. В этом, на мой взгляд, и заключается одна из проблем подобных систем: большинство из них не позволяет решать специфичные и узконаправленные проблемы проектного управления. Например, системы управления проектами и задачами, такие как Microsoft Project или JIRA, хорошо подходят для решения типовых задач и проблем, однако их полезность в разрешении конкретных ситуаций, специфичных для конкретного вида бизнеса, может быть спорной. Допустим, если компания работает в сфере приёма платежей, то в ходе реализации проектов у проектных менеджеров, помимо классических задач планирования и распределения работ, существуют задачи, не решаемые с помощью классического ПО.

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

Повышение эффективности принятия решений в задачах управления портфелем ИТ-проектов возможно с помощью моделирования процесса принятия решений [2]. Понятие эффективности управления проектами в различных организациях понимается по-разному. В широком смысле, под эффективностью понимают связь между достигнутым результатом и использованными ресурсами. В ITIL Continual Service Improvement [3] под эффективностью понимается мера целесообразности использования ресурсов для реализации процесса, услуги или деятельности. Эффективный процесс достигает своих целей с минимальными затратами времени, денег, людских и других ресурсов. То есть, эффективность управления проектом – это критерий достижения некоторой цели проекта, наивысших качественных и количественных показателей при наименьших затратах. Понятие эффективности управления, естественно, тесно связано с классическим понятием экономической эффективности. Данная связь объясняется тем, что в ИТ-проектах значительное влияние на показатели инвестиционной привлекательности оказывают именно эффективные и неэффективные управленческие решения. Согласно исследованию Harvard Business Review [4], один из шести крупных ИТ-проектов имеет средний перерасход бюджета более чем на 200%, а срок реализации проекта в среднем на 70% больше запланированного. Данная статистика подтверждает предположение, что именно проектные решения во многом определяют то, сколько прибыли конкретный проект принесёт бизнесу.

Существует классическое понимание набора этапов процесса принятия решений – рациональная модель. В рамках модели выделяют следующие этапы: диагностика проблемы, формулировка ограничений, определение альтернатив, оценка альтернатив, выбор альтернативы, реализация и контроль выполнения решений. К сожалению, данная модель имеет достаточно высокий уровень абстракции, что не позволяет в таком виде применять её на практике. В реальных бизнес-ситуациях, как правило, процесс разработки и принятия решения оказывается гораздо более многоэтапным и индивидуальным. При этом, как известно, принятие решений редко ограничивается простым выбором некоторого варианта из определённых альтернатив. В большинстве случаев необходимо принятие целой системы решений, каждое из которых непосредственно влияет на другие решения, но при этом процесс принятия каждого из решений может быть индивидуальным. В задачах управления портфелем проектов процесс принятия решений играет значительную роль, являясь непосредственной частью глобального процесса управления. Такие процессы, как процесс инициации или процесс планирования, не могут рассматриваться отдельно от процесса принятия решений.

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

Кригер Александра Борисовна

Дальневосточный федеральный университет

кандидат физико-математических наук, доцент кафедры бизнес-информатики и экономико-математических методов

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

Особенности организации таких предприятий:

• предприятие является малым и обладает штатом, состоящим из 5-8 сотрудников;
  
• для выполнения некоторых работ привлекаются сотрудники на договорной основе – фрилансеры;
• для функционирования предприятия необходима автоматизированная информационная система (АИС).

Однако предприятие сможет закрепиться на рынке только при эффективной организации бизнес-процессов. Под бизнес-процессом будем понимать совокупность связанных видов деятельности, направленных на получение конкретного продукта (результата), имеющего ценность для потребителя [1].

Таким образом, необходимо разработать модель сети бизнес-процессов компании (бронирование билетов на транспорт, заказ экскурсий и аренда транспортных средств). Построение модели процессов позволяет оценить степень их соответствие целям и повысить эффективность [2].

    В настоящее время существует несколько методов и методологий моделирования бизнес-процессов [3]:

• метод функционального моделирования методологии SADT (IDEF0);
  
• метод моделирования потоков работ методологии SADT (IDEF3);
  
• диаграмма Гейна-Сарсона (диаграмма потоков данных);
  
• методы методологии ARIS (EPC ERM, UML);
• нотация BPMN.

Для модерирования была выбрана нотация BPMN (Business process model and notation) [4]. Нотация универсальна для понимания и использует набор интуитивно понятных элементов, объединение которых можно просто и четко прочесть. Несмотря на это нотация плохо понимаема управленцами. С помощью BPMN можно отражать сценарий выполнения бизнес процесса, но одним из главных недостатков нотации является невозможность отобразить материальные потоки.

    На рынке программного обеспечения представлены разнообразные программные средства моделирования бизнес-процессов:

• BPWin (разработчик – Computer Association);
  
• Rational Rose (разработчик – IBM);
  
• Visio (разработчик – Microsoft);
• другие.

Для моделирования сети бизнес-процессов было выбрано программное средство Visio. Microsoft Visio поддерживает BPMN 2.0, который является текущей версией стандарта, и содержит соответствующие правила проверки схем.

Сеть бизнес-процессов – это совокупность связанных между собой бизнес-процессов, включающих в себя все основные операции (функции), которые выполняются в подразделении данной организации. [5] Построив сеть бизнес-процессов организации, можно оценить модель ее деятельности в целом и понять, правильно ли были выделены бизнес-процессы. Исходя из логики построения сети, можно также проверить, насколько корректно были описаны окружения бизнес-процессов, а именно — входные и выходные данные и ресурсы. Для моделирования из сети бизнес-процессов компании были выбраны следующие бизнес-процессы:

• заказ билетов;
  
• аренда автомобилей/байков/велосипедов;
• заказ экскурсий.

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

Участниками бизнес-процесса «Заказ билетов» (рисунок 1) являются партнеры поставщики транспортных услуг, турист и такое подразделение туристической компании, как отдел менеджеров. Бизнес-процесс имеет свернутый подпроцесс «Формирование группы», который включает в себя действия по формированию группы клиентов со сходными пожеланиями, а также действие компенсацию «Изменение покупки», так как при «Получении подтверждения покупки» может возникнуть ситуация, что какие-либо данные неверны и это необходимо исправить.

Рисунок 1 – Заказ билетов

Участниками бизнес-процесса «Заказ экскурсий» (рисунок 2) являются партнеры поставщики экскурсионных и транспортных услуг, турист и такое подразделение туристической компании, как отдел менеджеров. Бизнес-процесс имеет свернутый подпроцесс «Формирование групп на экскурсии», объединяющий в себе действия по составлению предварительных списков туристов, изъявивших желание посетить экскурсию с последующей оценкой соответствия размера группы условиям получения оптовой скидки. Также в бизнес-процессе представлено действие компенсации «Заказ индивидуального транспорта», так как при «Заказе транспорта до места проведения» может возникнуть ситуация, когда кто-то из туристов захочет добираться отдельно от группы и менеджеру необходимо это учитывать.

Рисунок 2 – Заказ экскурсий

Участниками бизнес-процесса «Аренда автомобиля/байка/велосипеда» (рисунок 3) являются компания по прокату транспортных средств, турист и сотрудники туристической компании: менеджер по работе с клиентами и менеджер по доставки транспортных средств.

Данный бизнес-процесс включает в себя несколько подпроцессов:

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

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

Рисунок 3 – Аренда транспорта

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

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

ФГБОУ ВО «Орловский государственный аграрный университет им. Н.В.Парахина»

Эконометрика — наука, в которой на базе реальных статистических данных строятся, анализируются и совершенствуются математические модели реальных экономических явлений [3].

Основные задачи эконометрики:

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

2. Анализ параметров построенной модели, делающих выбранную модель наиболее соответствующей настоящим сведениям.

3. Проверка качества найденных параметров модели и самой модели в целом.

4. Применение построенных моделей для объяснения поведения исследуемых экономических показателей, прогнозирования и предсказания, а также с целью осознанного проведения экономической политики[2].

Наиболее важной задачей является оценка и проверка экономической модели.

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

Эконометрическое моделирование широко используется в различных сферах современной жизни, как в технических, так и социально-экономических. Сочетая в себе приемы экономической теории, экономической и математической статистик, а также различные инструменты математики и информационных технологий, специалисты овладели уникальным инструментом при оценке технико–экономических процессов,  построении прогнозной и точностной характеристик всех этапов производства с целью установления и повышения качества и надежности изделий;  использовании методов экспертных оценок в случаях принятия [4].

Следует отметить, что эконометрическое моделирование основано на 6 этапах:

1)  Постановка целей и задач исследования, определение основных результативных и факторных переменных с учетом отсутствия эффекта мультиколлинеарности (переменные не должны быть высоко коррелированными между собой);

2)  Построение экономической задачи или априорный этап, в ходе которого следует проанализировать теоретически сущность исследуемого явления и выдвинуть соответствующие гипотезы и некоторые допущения [6];

3)  Моделирование (этап параметризации) предназначен для окончательного определения вида модели, формы связи. При этом следует отметить, что моделирование может быть статистическим и динамическим. Статистическое подразумевает моделирование взаимосвязи между статистически однородными данными. Например, это может быть выборка предприятий одной отрасли по размеру прибыли, объему выпускаемой продукции, уровню производительности труда или фондоотдачи т .д. Динамическое в свою очередь связывает значения результирующего признака в определенные моменты времени с соответствующими для этих периодов факторными (независимыми) переменными. Например, объем ВВП страны  или объем импорта/экспорта товаров за десятилетие может зависеть от нескольких факторов: уровня инфляции, курса доллара и т. д [5].

В ходе выполнения расчетной части  моделирования подбирают соответствующую функцию, которая может быть линейной или нелинейной. В настоящее время существует множество программных продуктов, которые облегчают выполнение трудоемких расчетов на этапе моделирования. Так, например, широко используется Microsoft Excel. Благодаря наличию соответствующего инструментария в интерфейсе программы, можно при однофакторном моделировании добавлять линию тренда с соответствующим представлением модели и коэффициента детерминации, либо проводить анализ множественной регрессии с помощью функции «Регрессия» и т.д [4].

4)  Идентификация модели, в ходе которого происходит оценка неизвестных параметром процесса.

5)  Оценка качества модели, в ходе которой проверяется успешность решения задач идентификации с помощью оценки на достоверность и адекватность. Чаще всего это происходит с помощью коэффициента детерминации, средней ошибки аппроксимации, по критерию F–Фишера и т.д.

6) Интерпретация результатов моделирования[1].

Данные этапы носят условный характер, так как они могут пересекаться, взаимно дополнять друг друга.

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

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

Для управления транспортно-логистическими процессами (ТЛП) нужно было описать эти процессы. Для моделирования транспортно-логистических процессов была разработана имитационная модель, состоящая из трех основных процессов в программе Anylogic. Экспериментально была проверена созданная модель и найдены недостатки в работе ТЛП. Были проанализированы результаты проведенного эксперимента. Две зоны (комплектация и отгрузка) на складе из 6 зон (разгрузка, приемка, временное хранение, складское помещение, комплектация, отгрузка) были перегружены в связи этим и появлялись сбои в работе. Большое количество ошибок, простои машин [6]. Далее были проведены эксперименты по изменению заданных первоначально 26 параметров для нахождения состояния, когда не будет перегрузки всех 6 зон. При уменьшении затрат времени на выполнение операций в зоне комплектации, отгрузки и в зоне складирования достигается состояние когда зоны не перегружены. Эксперимент  с моделью показал, что в течение 3 дней работы имитационной модели зоны не переполнялись. Для достижения данного эффекта в имитационной модели, т.е. сокращения выполнения операций в трех зонах были предложены мероприятия [2, 3].

Предлагались рекомендации по совершенствованию транспортно-логистических процессов на предприятии. Было предложено мероприятие по повышению эффективности логистической деятельности предлагается автоматизация склада с применением технологии штрихкодирования. Применительно к организации  данная технология крайне актуальна, так как штрихкодирование товаров применяется при упаковке товаров, в связи с необходимостью маркировки, но не при операциях приемки, сборки заказов и отгрузке товаров на складе готовой продукции. Это неизбежно приводит к потере времени при выполнении складских операций. Еще одним мероприятием является Multipicking – это технология, позволяющая отборщику одновременно собирать несколько листов отбора под различные заказы, что в свою очередь оптимизирует работу склада в целом. Кроме того, отсутствует необходимость сортировки после отбора, существует возможность гибкой настройки количество отбираемых листов. Wavepicking – волновая комплектация. Прежде чем начать использовать волновую комплектацию заказов, надо сгруппировать товары на складе в разрезе значимых характеристик. Заключительным мероприятием, влияющим на производительность склада, а в большей степени зоны комплектации, является внедрение адресной системы хранения. Суть данного мероприятия – разбить складское помещение на участки, и каждому из них назначить свой адрес и присвоить штрих-код, тогда любой такой участок, независимо от его физических характеристик, будет называться ячейкой. В случае, если одна партия готовой продукции размещается на нескольких паллетах, ячейки объединяются в области для быстрого и гибкого оперирования ими [4, 5].

Была рассчитана экономическая эффективность предложенных мероприятий по отдельности и в целом показан эффект. Благодаря мероприятиям произошло повышение производительности труда в зоне комплектации до 25% на один заказ. В зоне приемки  экономия времени составила 20-25%. Сократилось до 30% время погрузки машины. Сократились количество ошибки при комплектации, отгрузки и приемки на 30-35%.

Интенсификация и повышение точности балансовых расчетов и прогнозов расходов и доходы.

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

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

Ввод данных: прогнозные значения доходов и расходов по отношению к расчетной базе объектов бюджетной системы;

Выходные данные: бюджет проекта близко к реальному исполнению;

Влияние внешних факторов на системы – изменения планируемых поступлений и расходов;

Результат работы модели—возможность регулирования бюджета проекта в соответствии с реальным исполнением.
Пусть m-количество элементов дохода, из которых формируется бюджет, и

n - количество статей расходов, по которым бюджет должен быть распределен. Исходя из предположения о пропорциональном распределении каждой единицы дохода среди всех статей расходов, введем коэффициент, отражающий долю каждого элемента дохода в данной статье расходов:

 (1.1)

где - абсолютное значение i-й статьи расходов;

 - абсолютное значение j-го дохода;

  – коэффициент взаимодействия доходов и расходов.

Коэффициенты взаимодействия можно рассматривать как:

• распределение элемента дохода
• формирование расходов

С точки зрения формирования каждого фиксированного i-го элемента расходов (включая все статьи доходов), имеем:

В матричной форме связь между доходами и расходами статей можно записать в виде:

где А - является матрицей взаимодействий между доходных и расходных статей размера n Ч m.

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

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

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

Пусть векторы X0 и Y0 характеризуют сбалансированное состояние бюджета. Согласно (1.4), мы имеем:

или в координатной форме

где  являются, соответственно, векторами доходов и расходов для сбалансированного состояния бюджета; m - это количество статей бюджета; и матрица взаимодействий, приводящий бюджет в сбалансированное состояние.

С точки зрения распределения каждого фиксированного j-го дохода среди всех статей расходов, , имеем:

Равенство (1.13) справедливо и для ситуации баланса:

Равенства (1.9) и (1.5) позволяют сделать вывод: сумма элементов j-го столбца матрицы баланса взаимодействия равно отношению всех сбалансированных бюджетов дохода к доходу j-го элемента.

На самом деле, для сбалансированного состояния бюджета элементов матрицы взаимодействия 

откуда (с теми же обозначениями) мы имеем:

Очевидным следствием (1.10) является утверждение, что каждый i-й элемент сбалансированного бюджета является отношением самого сбалансированного бюджета на сумму коэффициентов взаимодействия для всех статей расходов, среди которых j-й был распространен как:

Рассмотрим сумму запланированных акций бюджета:

Для следующих вариантов государственного бюджета как: баланс, профицит и дефицит. Согласно (1.13) имеем:

Следовательно, (1.14) может быть использована для анализа состояния бюджета:
если  , для сбалансированного государственного бюджета

если , для дефицитного государственного бюджета, и дефицитная доля это:

если , для профицитного (или избыточного) государственного бюджета, и профицитная доля это:
Поэтому государственный бюджет определяется на основе информации о значениях элементах в матрице взаимодействия А.

Один из этапов проектирования баз данных (концептуальное проектирование) предполагает сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия: обследование предметной области, изучение ее информационной структуры, выявление всех фрагментов, каждый из которых характеризуется пользовательским представлением, информационными объектами и связями между ними, процессами над информационными объектами моделирование и интеграция всех представлений.

Использование разрабатываемого продукта для управления расселением обучающихся в общежитиях предполагает создание комиссии по заселению, которая будет принимать критерии, их устанавливать приоритет. По каждому критерию будет формироваться список студентов в порядке убывания приоритета заселения. Все критерии можно разместить в одной таблице, в которой рейтинг студента будет являться средневзвешенным значением по всем критериям. Для критериев комиссией по заселению принимаются начальные условия, в зависимости от которых формируется рейтинг студентов. Для каждой из имеющихся льгот устанавливается коэффициент важности. При наличии нескольких льгот коэффициенты суммируются. Для формирования рейтинга по удаленности проживания комиссией по заселению принимается максимальное расстояние. Считается, что все населенные пункты, находящиеся дальше этого расстояния, имеют первоочередный приоритет при заселении. Так же комиссией по заселению может быть принят средний доход на человека, при этом все студенты, имеющие значение дохода ниже среднего, будут считаться студентами из малообеспеченных семей. В результате, для каждого студента формируется 5 рейтингов каждого отдельно взятого критерия, а также суммарный рейтинг, при расчете которого учитывается коэффициент важности критериев. Рассмотрим на примере табл.1.

Таблица 1. Коэффициенты важности критериев

К примеру, имеются 4 студента. Их рейтинги представлены в табл.2.

В результате два студента имеют одинаковый рейтинговый показатель. В этой ситуации будет учитываться первоочередной критерий, который примет комиссия по заселению. В данном случае это критерий «Имеющиеся льготы». Таким образом., системой будет определен следующий итоговый рейтинг:

1. Приподобный.
2. Ткач.
3. Шевченко.
4. Деркач.

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