Моделирование бизнес-процессов на примере ООО 'ПромТрансИнформ'
Аннотация
информационный моделирование бизнес
В данной работе рассматриваются бизнес-процессы ООО «ПромТрансИнформ» -
далее ПТИ.
Были рассмотрены и изучены:
· общая характеристика предприятия;
Были рассмотрены виды деятельности организации, какие продукты она
внедряет и какие услуги оказывает, с какими организациями (в частности
крупнейшими) заключены договоры и как это влияет на деятельность организации.
· описаны методологии описания бизнес-процессов;
В основном применяется в ПТИ методология ARIS,которая позволяет рассматривать организацию со всех
точек зрения и позволяет рассмотреть организацию с помощью иерархии моделей -
от обобщения до уровня процедур и ресурсного окружения функций.
· построены диаграммы бизнес-моделей (в нотациях ARIS с помощью CASE-средства
Microsoft Visio) «AS IS» (как есть);
· найдено «узкое место» и, на примере модели eEPC, изображена модель «AS TO BE» (как должно быть);
«Узким местом» в данной курсовой является слабая организация рабочего
процесса, которая возникает, когда обязанности распределены не рационально, что
тормозит выполнение заказа.
· написано соглашение по моделированию и документирование бизнес-процесса;
· проведен анализ процесса.
Введение
Цель работы заключается в моделировании бизнес-процессов ООО «ПромТрансИнформ»,
выявление недостатков в деятельности конкретных отделов и предложение способа
их устранения.
Вопрос об улучшении деятельности предприятия за счет нахождения и
устранения, так называемых, «узких мест» в работе сотрудников, с помощью
моделирования бизнес-процессов является актуальным в любом развивающемся
предприятии.
Объектом изучения, в данной курсовой работе, является ООО ПТИ и его
отделы, главной услугой которого - автоматизация предприятий промышленного
железнодорожного транспорта.
Предметом изучения является взаимодействие отделов и сотрудников в этих
отделах, подчиняющихся Генеральному директору.
Задачи работы: обучение навыкам работы с методологией моделирования
бизнес-процессов ARIS, сбор
информации и изучение бизнес-процессов предприятия, процедур моделирования,
построение диаграмм бизнес-моделей, разработка соглашения по моделированию и
документирование бизнес-процесса, проведение анализа процесса.
Методы работы. Работа выполняется с целью повышения навыков построения
диаграмм бизнес-моделей в нотациях ARIS с помощью CASE-средства Microsoft Visio на примере бизнес-процессов ОАО «ПТИ».
В качестве исходных данных в работе используются следующие сведения:
· организационно-штатная структура предприятия;
· характеристика предприятия;
· организация проектирования в консалтинговых предприятиях;
· сведения об используемых прикладных системах ПТИ.
В результате проделанной работы и устранении «узких мест» ожидается
упрощение и облегчение работа сотрудников, следовательно, уменьшение
трудоемкости и совершения ошибок в отчетах.
1. Архитектура интегрированных информационных систем ARIS как методология
моделирования бизнес-процессов
Разработчиком методологии ARIS (Architecture of Integrated Information Systems) является компания IDS Scheer AG, основанная в 1984 г. профессором Августом-Вильгельмом
Шеером в г. Саарбрюккен (Саар, Германия). Методология ARIS представляет собой современный подход к
структурированному описанию деятельности организации и ее представлению в виде
взаимосвязанных и взаимодополняющих графических моделей, удобных для понимания
и анализа.
Модели, используемые в ARIS,
представлены на рисунке 1.1.
Рисунок 1.1 - Классификация моделей ARIS
Модели, создаваемые по методологии ARIS, отражают существующую ситуацию с
той или иной степенью приближенности. Степень детализации описания зависит от
целей проекта, в рамках которого проводится моделирование. Модели ARIS могут
быть использованы для анализа и выработки различного рода решений по
реорганизации деятельности предприятия, в том числе по внедрению информационной
системы управления, разработке систем менеджмента качества.
Методология ARIS реализует принципы структурного анализа и позволяет
определить и отразить в моделях основные компоненты организации, протекающие
процессы, производимую и потребляемую продукцию, используемую информацию, а так
же выявить взаимосвязи между ними. Создаваемые модели представляют собой
документированную совокупность знаний о системе управления, включая
организационную структуру, протекающие процессы, взаимодействия между
организацией и субъектами рынка, состав и структуру документов,
последовательность шагов процессов, должностные инструкции отделов и их
сотрудников. В отличие от других подходов, методология ARIS предполагает хранение
всей информации в едином репозитории, что обеспечивает целостность и
непротиворечивость процесса моделирования и анализа, а также позволяет
проводить верификацию моделей.
Методология ARIS основывается
на концепции интеграции, предлагающей целостный взгляд на процессы, и
представляет собой множество различных методик, объединенных в рамках единого
системного подхода. Среди них такие известные, как:
· диаграмма eEPC (Extended Event Driven Process Chain - событийная цепочка
процесса)
· диаграмма Чена (ERM - Entity
Relationship Model - модель
"сущность - связь")
· язык UML (Unified Modeling Language - универсальный язык моделирования)
· методика OMT (Object Modeling Technique - методика объектно-ориентированного
моделирования)
· методика BSC (Balanced Scorecard - система сбалансированных
показателей) Достоинством такого подхода является то, что появляется
возможность описания процессов и их окружения с различных, взаимодополняющих
точек зрения.
2. Преимущества и недостатки существующих методологий моделирования
бизнес-процессов
Методология ARIS.
Преимущества:
· возможность рассматривать объект с разных точек зрения; разные уровни
описания, обеспечивающие поддержку концепции жизненного цикла систем;
дифференцированный взгляд на анализируемый объект (организацию, систему
управления и т.д.);
· богатство методов моделирования, отражающих различные аспекты
исследуемой предметной области, позволяет моделировать широкий спектр систем
(организационно-хозяйственных, технологических и прочих);
· единый репозиторий; все модели и объекты создаются и хранятся
в единой базе проекта, что обеспечивает построение интегрированной и целостной
модели предметной области;
· возможность многократного применения результатов
моделирования; накопленное корпоративное знание о всех аспектах деятельности
организации может в дальнейшем служить основой при разработке различных
проектов непосредственно в среде ARIS и с использованием интерфейсов и других
средств.
Недостатки:
· Для некоторых процессов чрезмерная формализация не только малоэффективна,
но даже вредна в силу их специфики. Примером могут являться те составляющие
бизнес - деятельности, которые напрямую связаны с творческими решениями
малопрогнозируемых проблем, возникающих в ходе этой деятельности.
· Высокая стоимость продукта.
SADT (Structured Analysis and Design Technique) - методология
структурного анализа и проектирования, интегрирующая процесс моделирования,
управление конфигурацией проекта, использование дополнительных языковых средств
и руководство проектом со своим графическим языком. Процесс моделирования может
быть разделен на несколько этапов: опрос экспертов, создание диаграмм и
моделей, распространение документации, оценка адекватности моделей и принятие
их для дальнейшего использования. Этот процесс хорошо отлажен, потому что при
разработке проекта специалисты выполняют конкретные обязанности, а библиотекарь
обеспечивает своевременный обмен информацией.возникла в конце 60-х годов в ходе
революции, вызванной структурным программированием. Когда большинство специалистов
билось над созданием программного обеспечения, немногие старались разрешить
более сложную задачу создания крупномасштабных систем, включающих как людей и
машины, так и программное обеспечение, аналогичных системам, применяемым в
телефонной связи, промышленности, управлении и контроле за вооружением. В то
время специалисты, традиционно занимавшиеся созданием крупномасштабных систем,
стали осознавать необходимость большей упорядоченности. Таким образом,
разработчики решили формализовать процесс создания системы, разбив его на
следующие фазы:
· Анализ - определение того, что система будет делать
· Проектирование - определение подсистем и их взаимодействие
· Реализация - разработка подсистем по отдельности
· Объединение - соединение подсистем в единое целое
· Тестирование - проверка работы системы
· Установка - введение системы в действие
· Эксплуатация - использование системы
Метод SADT в наибольшей степени подходит для
описания моделей верхнего уровня. Его основные преимущества заключаются в
следующем:
· полнота описания БП (управления, информационные и материальные потоки,
обратные связи).
· Комплексность декомпозиции
· Возможность агрегирования и детализации потоков данных и
информации (разделение и слияние дуг)
· Наличие жестких требований, обеспечивающих получение модели
стандартного вида.
· Простота документирования процесса
· Соответствие подхода к описанию процесса стандарту ИССО
В то же время SADT обладает
рядом недостатков:
· Сложность восприятия - большое количество дуг на диаграмме.
· Большое количество уровней декомпозиции
· Трудность увязки нескольких процессов, представленных в
различных моделях одной и той же организации.
IDEF0
Методология функционального моделирования. С помощью наглядного
графического языка IDEF0, изучаемая система предстает перед разработчиками и
аналитиками в виде набора взаимосвязанных функций (функциональных блоков - в
терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым
этапом изучения любой системы.
Основные преимущества IDEF0 состоят в следующем:
· полнота описания бизнес-процесса (управление, информационные и
материальные потоки, обратные связи);
· комплексность при декомпозиции (мигрирование и туннелирование
стрелок);
· возможность агрегирования и детализации потоков данных и
информации (разделение и слияние стрелок);
· наличие жестких требований методологии, обеспечивающих
получение моделей процессов стандартного вида;
· простота документирования процессов;
· соответствие подхода к описанию процессов в IDEF0 стандартам
ISO 9000:2000.
Отсюда и общее назначение IDEF0 - это перестройка структуры функций,
которая позволит повысить производительность и эффективность системы.
Методология IDEF3 (Integrated Definition Process Description Capture
Method) была разработана с целью более удобного описания рабочих процессов
(Work Flow), для которых важно отразить логическую последовательность
выполнения процедур. Эта методика, в отличии от IDEF0, не стандартизирована. -
это структурный метод, показывающий причинно-следственные связи и события. Он
также показывает, как организована работа, и какие пользователи работают с
моделируемой системой. С помощью IDEF3 описываются сценарий и
последовательность операций для каждого процесса. Сценарием называется описание
последовательности изменения свойств объекта в рамках рассматриваемого процесса
(например, описание последовательности этапов обработки детали в цеху и
изменение ее свойств после прохождения каждого этапа). Исполнение каждого
сценария сопровождается соответствующим документооборотом, который состоит из двух
потоков: документы, определяющие структуру и последовательность процесса
(технологические указания, описания стандартов) и документы, отображающие ход
его выполнения (результаты экспертиз, отчеты о браке).
Средства документирования и моделирования IDEF3 позволяют выполнять
следующие задачи:
· документировать имеющиеся данные о технологии процесса;
· определять и анализировать точки влияния потоков
сопутствующего документооборота на сценарий технологических процессов;
· определять ситуации, в которых требуется принятие решения,
влияющего на жизненный цикл процесса (например, изменение технологических
свойств конечного продукта);
· содействовать принятию оптимальных решений при реорганизации
технологических процессов;
· разрабатывать имитационные модели технологических процессов
по принципу «как будет, если...».
IDEF3 имеет прямую взаимосвязь с методологией IDEF0 - каждая функция
может быть представлена в виде отдельного процесса средствами IDEF3. Но
функциональное моделирование в IDEF3 отличается от моделирования в IDEF0 и DFD,
тем что она отражает функции системы во временной последовательности их
осуществления.
Методология DFD (Data Flow Diagrams) - диаграммы потоков данных - это
способ представления процессов обработки информации. Авторы методики Гейн и
Сарсон разработали ее независимо от IDEF0. Эта методика, в отличии от IDEF0 не
стандартизирована.
В отличие от стрелок IDEF0, которые представляют собой жесткие
взаимосвязи, стрелки DFD (потоки данных) показывают, как объекты (включая и
данные) реально перемещаются от одной функции к другой. Это представление
потока данных обеспечивает отражение в модели DFD таких физических
характеристик системы, как движение объектов, хранение объектов,
распространение объектов.
Диаграммы DFD обеспечивают удобный способ описания передаваемой
информации как между частями моделируемой системы, так и между системой и
внешним миром. Это качество определяет область применения DFD - они
используются для создания моделей информационного обмена организации, например,
модели документооборота. Также DFD широко применяется при построении
корпоративных информационных систем. Modeling Language (UML), унифицированный
язык моделирования, непатентованный язык моделирования и спецификации,
предназначенный для использования в области разработки программного
обеспечения. Тем не менее, сфера его применения не ограничивается областью
моделирования информационных систем. Он также может быть использован для
моделирования инженерных систем, бизнес-процессов, организационных структур.
UML - язык используемый системными инженерами для спецификации, визуализации,
конструирования и документирования сложных информационно-насыщенных объектных
систем.
Преимущества
UML
· UML объектно-ориентирован, в результате чего методы описания
результатов анализа и проектирования семантически близки к методам
программирования на современных объектно-ориентированных языках;
· UML позволяет описать систему практически со всех возможных
точек зрения и разные аспекты поведения системы;
· Диаграммы UML сравнительно просты для чтения после достаточно
быстрого ознакомления с его синтаксисом;
· UML расширяет и позволяет вводить собственные текстовые и
графические стереотипы, что способствует его применению не только в сфере
программной инженерии;
· UML получил широкое распространение и динамично развивается.
Недостатки:
· Избыточность языка. UML часто критикуется, как неоправданно
большой и сложный. Он включает много избыточных или практически неиспользуемых
диаграмм и конструкций.
· Неточная семантика. Так как UML определён комбинацией себя
(абстрактный синтаксис), OCL (языком описания ограничений - формальной проверки
правильности) и Английского (подробная семантика), то он лишен скованности
присущей языкам, точно определённым техниками формального описания. В некоторых
случаях абстрактный синтаксис UML, OCL и Английский противоречат друг другу, в
других случаях они неполные. Неточность описания самого UML одинаково
отражается на пользователях и поставщиках инструментов, приводя к
несовместимости инструментов из-за уникального трактования спецификаций.
· Проблемы при изучении и внедрении. Вышеописанные проблемы
делают проблематичным изучение и внедрение UML, особенно когда руководство
насильно заставляет использовать UML бизнес-аналитиков при отсутствии у них
предварительных навыков.
· Пытается быть всем для всех. UML - это язык моделирования
общего назначения, который пытается достигнуть совместимости со всеми
возможными языками разработки. В контексте конкретного проекта, для достижения
командой проектировщиков определённой цели, должны быть выбраны применимые
возможности UML. Кроме того, пути ограничения области применения UML в
конкретной области проходят через формализм, который не полностью
сформулирован, и который сам является объектом критики.
3. Выбор бизнес-процесса для моделирования и его содержательное описание
.1 Общая характеристика предприятия
ООО ПромТрансИнформ занимается автоматизацией
предприятий промышленного железнодорожного транспорта за счет внедрения
информационных компонентов программно-технического комплекса Интегрированной
информационной системы управления «Транспортно-логистический комплекс»,
управлением проектами внедрения специализированных информационных систем
управления на магистральном железнодорожном транспорте, а также управлением
проектами внедрения на территории Республики Казахстан приборов, устройств и
информационных систем железнодорожной автоматики и телемеханики,оказывает
консалтинговые услуги в этой сфере.
Основными направлениями деятельности ООО «ПромТрансИнформ» являются:
-Автоматизация железнодорожных предприятий, которая работает с такими
ИТ-продуктами, как ИАС «Транспортная работа»,ИАС «Эксплуатационные расходы»,
ИАС «Транспортные активы»,ИАС «Взаимодействие с клиентами»,ИАС «Эффективность
логистики».
Аппаратно-программный комплекс ИАС ТР является частью
программно-технической платформы «PTI Framework .Net.2.1.», на котором построена Интегрированная
информационная система управления «Железнодорожный комплекс» (ИИСУ «ЖДК»)
Данный комплекс является специализированным решением ООО «ПромТрансИнформ»,
базирующимся на ИТ-продуктах линейки .NET компании Microsoft.
ИАС ТР использует значительный объем встроенной бизнес-логики,
обеспечивающей автоматизированное ведение процессов управления железнодорожным
комплексом Заказчика.
Информационно-аналитическая система «Транспортная работа» (далее «ИАС
ТР»), разработана специалистами ООО «ПромТрансИнформ» (г. Новосибирск).
Основной целью внедрения ИАС ТР является комплексная автоматизация
управленческих бизнес-процессов производственного планирования и учета объемов
и стоимости:
Транспортной
логистики (перевозок);
Транспортной (логистической) работы;
Транспортного
обслуживания клиентов (оказания транспортных услуг);
Транспортных
расходов (себестоимости работ и тарифов на услуги);
Эксплуатации транспортных активов железнодорожного
предприятия на подъездном пути и в магистральном движении.
Она учитывает отраслевые отличия
производственно-экономической деятельности железнодорожных предприятий (по
сравнению с деятельностью промышленных предприятий)
Также ООО ПромТрансИнформ занимается транспортным и экономическим
консалтингом (Транспортно-логические комплексы на ж/д, Транспортный консалтинг
на ж/д транспорте, Экономический консалтинг на ж/д транспорте, ИТ-Консалтинг на
ж/д транспорте, Методические руководства по ж/д тарифам) и управлением
проектами на ж/д предприятиях (внедрение информационных систем на ж/д
транспорте, оптимизация бизнес-процессов железнодорожной транспортной
логистики, оптимизация эксплуатационных расходов железнодорожного транспортного
комплекса, внедрение систем управления проектами).
Основными партнерами и заказчиками ООО
«ПромТрансИнформ» являются предприятия промышленного железнодорожного комплекса
железнодорожной отрасли Республики Казахстан и России.
Основным методологическим партнером ООО
«ПромТрансИнформ» является ГОУ «Сибирский государственный университет путей
сообщения» (г.Новосибирск).Специалисты компании имеют 6 - летний опыт работы в
железнодорожной отрасли.
3.2 Область обследования
В качестве исследуемого объекта возьмем ООО «ПромТрансИнформ», а именно
процесс организации рабочего процесса. Исследовав это предприятия и пообщавшись
с сотрудниками, можно определить, что налицо слабая организация рабочего
процесса. Более полное описание «узкого места» и способы его устранения
представлены в разделе «Анализ процесса».
Организационная структура ООО «ПромТрансИнформ» (рисунок 3.1):
Рисунок 3.1-Оргструктура ПТИ
3.3 Порядок проведения обследования
· Место проведения обследования - здание ООО ПромТрансИнформ ул.Красный
проспект, 220/5,оф.326 (Сибирская Ярмарка);
· Способ обследования - интервью с сотрудниками ООО
ПромТрансИнформ в устной форме, получение необходимой документации в
электронном виде.
4. Моделирование «AS IS» (как есть), описание подхода. выбор и
обоснование типов диаграмм, используемых для описания бизнес-процесса
средствами ARIS
Каждое предприятие имеет структуры, правила и документы, которые
составляют основу для исправного функционирования корпоративных процедур и
должны быть интегрированы с новой системой управления качеством. Анализ
"Как есть" предполагает исследование внедряемого стандарта с учетом
спецификации компании. Цель такого анализа - выяснение требований стандарта, и
в какой мере они затрагивают конкретные аспекты деятельности компании. На этом
же этапе в рамках компании проводится инвентаризация документов и информационных
систем, имеющих отношение к качеству.
Для моделирования процессов ООО «ПромТрансИнформ» будем использовать
следующие диаграммы:
· Organizational chart - описание организационной структуры отдела.
· Knowledge map - отображение типов знаний работников ПТИ и
структуризации форм их хранения для определения возможностей, которыми они
располагают.
· Authorization map - описание полномочий работников.
· Informational carrier diagram - описание документов для удобства описания
процессов, происходящих в отделе.
· Function Tree - разделение функций, выполняемых отделом, на уровни
для более наглядного представления деятельности отдела.
· Function allocation diagram - описание объектов, окружающих функцию, для
наглядного представления сложной функции.
· Communication diagram - представление взаимодействий организационных
единиц, для описания выполнения всего процесса производства.
· Risk diagram - для описания рисков, возникающих в процессе
деятельности.
· Product/Service Tree - для
структурирования продуктов, полученных в результате деятельности отдела.
· Technical resources model - для описания технических ресурсов, используемых в
отделе.
· Value-added chain diagram - описание процессов отдела,
влияющих на качество функционирования. Для описания видов деятельности ПТИ,
создающих добавленное качество выпускаемой продукции.
· Event-driven process
chain diagram - описание действий в рамках бизнес-процесса. Для
наглядного представления процессов, выполняемых отделом.
5. Соглашения по моделированию
Цель проекта по моделированию совпадает с целью курсового проекта и
представлена во введении. В донной работе рассмотрены модели «AS IS» (как есть) и «AS TO BE» (как должно быть). Способ
моделирования - сверху вниз.
Рассмотрено моделирование на следующих уровнях абстракции: типовые
бизнес-процессы и экземплярные бизнес-процессы.
Рассмотрены модели, относительно исходных данных: описание требований,
описание полномочий, должностные инструкции, услуги компании, функции
сотрудников.
Методология ARIS содержит
множество типов моделей, каждая из которых отнесена к определенному типу
представления и уровню описания. В работе используются следующая иерархия,
используемая для моделирования бизнес-процесса:
процессы верхнего уровня, к которым относятся диаграммы Organizational chart- Организационная структура ПТИ, Technical resources model - Технические ресурсы, Product/Service Tree -Продукты и
услуги ПТИ
подпроцессы, к которым относятся диаграмма Informational carrier diagram - Документы ПТИ
сценарии процессов, к которым относятся диаграмма Authorization map - Полномочия бизнес-аналитика
процедуры (операции), к которым относятся диаграммы Event-Driven Process
Chain , Knowledge map - Карта знаний бизнес-аналитика, Function allocation diagram - Окружение функции - процесс модернизации ИАС
«Транспортная работа» под клиента, Value-added chain diagram - Процедуры для процесса участия в конкурсе.
В предыдущем разделе были перечислены виды диаграмм, которые представлены
в курсовой работе. Элементы этих диаграмм детально описаны в соглашении по
моделированию.
5.1 Глоссарий терминов проекта
Соглашение по моделированию определяет трактовку следующих терминов,
используемых в проекте (таблица 5.1):
Таблица 5.1 - Глоссарий
|
Термин (рус.)
|
Термин (англ.)
|
Определение
|
|
Функция
|
Function
|
Действия сотрудников, выполняемые при появлении заданного
комплекса условий (событий) и направленные на получение требуемого
результата.
|
|
Событие
|
Event
|
Отражение изменения состояния внешней или внутренней среды,
выражающееся в наборе документов, принятых решениях, наступлении
определенного срока и пр. Является результатом выполняемого действия, а также
необходимостью выполнения одного или нескольких следующих действий. В отличие
от функций, которые отражают процесс, протекающий во времени и имеющий
определенную длительность, события происходят в одной точке во времени.
|
|
Бизнес-процесс
|
Business process
|
Связанный набор повторяемых действий (функций),
преобразующих исходный материал и (или) информацию в конечный продукт
(услугу) в соответствии с предварительно установленными правилами.
|
|
Продукт
|
Product
|
Продукт/услуга - результат человеческой деятельности или
технологического процесса. Продукт может быть как материальным, так и
нематериальным (услуга).
|
.2 Диаграмма событийно-управляемой цепочки процесса (extended Event-driven Process
Chain, eEPC)
Используемые объекты и их символы представлены в таблице 5.2.1.
Таблица 5.2.1 - используемые объекты
|
Тип объекта рус. (англ.)
|
Символ с именем по умолчанию (рус./англ.)
|
Целевое использование
|
Правила именования
|
|
Событие (Event)
|
|
Отображение событий, происходящих при выполнении
бизнес-процесса
|
Имя начинается с имени объекта, состояние или событие по
отношению к которому произошло
|
|
Носитель информации (Information carrier)
|
|
Представление информационного носителя данных в
нематериальной форме (напр., на магнитном диске или флеш-памяти)
|
Именуется названием файла или именем информационной базы
данных
|
|
Носитель информации (Information carrier)
|
|
Представление информационного носителя данных в
материализованном виде (напр., на бумаге)
|
Имя должно содержать наименование документа
|
|
Экземпляр функции (Function instance)
|
|
Описание экземпляра бизнес-функции в цепочке выполнения
бизнес-процесса.
|
Имя начинается с действия или обозначения процесса,
существенные характеристики которого приводятся далее в имени.
|
|
Должность (Position)
|
|
Представление должности сотрудника организации.
|
Полное название должности
|
|
Прикладная система (Application system)
|
|
Представление используемых прикладных систем
|
Имя содержит название экземпляра прикладной системы
|
Типы связей, используемых в диаграмме событийно-управляемой цепочки
процесса, представлены в таблице 5.2.2.
Таблица 5.2.2 - типы связей
|
Тип объекта-источника связи
|
Тип связи рус. (англ.)
|
Целевое использование
|
Тип объекта-приемника связи
|
|
Событие (Event)
|
Вызывает (activates)
|
Предназначена для вызова функции
|
Функция (Function)
|
|
Функция (Function)
|
Создает (creates)
|
Предназначена для описания создаваемого на выходе события
|
Событие (Event)
|
|
Функция (Function)
|
Приводит к (leads to)
|
Предназначена для описания итога выполнения
|
Правило (Rule)
|
|
Правило (Rule)
|
Вызывает (activates)
|
Предназначена для вызова функции
|
Функция (Function)
|
|
Правило (Rule)
|
Приводит к (leads to)
|
Предназначена для описания итога выполнения
|
Событие (Event)
|
|
Организационная единица (Organizational unit)
|
Выполняет (executes)
|
Предназначена для указания подразделения/лица, выполняющего
функцию
|
Функция (Function)
|
|
Должность (Position)
|
Выполняет (executes)
|
Предназначена для указания подразделения/лица, выполняющего
функцию
|
Функция (Function)
|
|
Носитель информации (Information carrier) Функция (Function)
|
Имеет
на входе (Provides input for)
|
Предназначена для описания документирования функции
|
Функция (Function)
|
|
Создает на выходе (Creates output to)
|
|
Носитель информации (Information carrier)
|
|
Прикладная система (Application system)
|
Поддерживает (Supports)
|
Предназначена для описания используемой прикладной системы
|
Функция (Function)
|
.3 Диаграмма организационной структуры предприятия (Organizational chart)
Таблица 5.3.1 - Используемые объекты
|
Тип объекта рус. (англ.)
|
Символ с именем по умолчанию (рус./англ.)
|
Целевое использование
|
Правила именования
|
|
Организационная единица (Organizational unit)
|
|
Обозначение отдельного штатного подразделения.
|
Полное название подразделения
|
|
Должность (Position)
|
|
Представление должности сотрудника организации.
|
Полное название должности
|
Типы связей, используемых в диаграмме организационной структуры,
представлены в таблице 5.3.2.
Таблица 5.3.2 - типы связей
|
Тип объекта-источника связи
|
Тип связи рус. (англ.)
|
Целевое использование
|
Тип объекта-приемника связи
|
|
Должность (Position)
|
является непосредственным руководителем (is disciplinary superior)
|
предназначена для указания руководителя организационной
единицы
|
Организационная единица (Organizational unit)
|
|
Должность (Position)
|
Организатор для (Is org manager)
|
предназначена для описания состава организационной единицы
|
Должность (Position)
|
5.4 Диаграмма структуры знаний (Knowledge structure
diagram)
Типы объектов, используемых в диаграмме структуры знаний, представлены в
таблице 5.4.1.
Таблица 5.4.1 - типы объектов
|
Тип объекта рус. (англ.)
|
Символ с именем по умолчанию (рус./англ.)
|
Целевое использование
|
Правила именования
|
|
Документированное знание (Documented knowledge)
|
|
Объект используется для идентификации формализованного
(задокументированного) объема знаний, необходимых для выполнения
бизнес-функции.
|
Полное название документа, содержащего информацию
|
|
Категория знаний (Knowledge category)
|
|
Представление знаний или умений, которыми должен обладать
сотрудник или необходимыми для успешного выполнения бизнес-функции.
|
Полуформальное определение необходимого объема знаний
|
|
Должность (Position)
|
|
Представление должности сотрудника организации.
|
Полное название должности
|
Типы связей, используемых в диаграмме структуры знаний, представлены в
таблице 5.4.2.
Таблица 5.4.2 - типы связей
|
Тип объекта-источника связи
|
Тип связи рус. (англ.)
|
Целевое использование
|
Тип объекта-приемника связи
|
|
Должность (Position)
|
Требует (requires)
|
Предназначена для описания требуемых знаний для данной
должности
|
Категория знаний (Knowledge category)
|
|
Категория знаний (Knowledge category)
|
Содержит (subsumes
|
Предназначена для описания документированных знаний,
необходимых сотруднику
|
Документированное знание (Documented knowledge)
|
|
Категория умений (Knowledge category)
|
Содержит (subsumes)
|
Предназначена для описания умений, необходимых сотруднику
|
Документированное знание (Documented knowledge)
|
.5 Диаграмма информационных носителей (Informational carrier diagram)
Типы объектов, используемых в диаграмме, представлены в таблице 5.5.1
Таблица 5.5.1 - Типы объектов
|
Тип объекта рус. (англ.)
|
Символ с именем по умолчанию (рус./англ.)
|
Целевое использование
|
Правила именования
|
|
Носитель информации (Information carrier)
|
|
Представление информационного носителя в материальной форме
|
Имя должно содержать наименование совокупности (картотеки)
документов
|
|
|
Представление носителя информации
|
Имя содержит название информации
|
|
|
Типы связей, используемых в диаграмме, представлены в таблице 5.5.2.
Таблица 5.5.2 - типы связей
|
Тип объекта-источника связи
|
Тип связи рус. (англ.)
|
Целевое использование
|
Тип объекта-приемника связи
|
|
Носитель информации (Information carrier)
|
Включает в себя (encompasses)
|
Предназначена для структурирования документов организации
|
Носитель информации (Information carrier)
|
.6 Карта полномочий (Authorization map)
Типы используемых объектов представлены в таблице 5.6.1.
Таблица 5.6.1 - типы объектов
|
Тип объекта рус. (англ.)
|
Символ с именем по умолчанию (рус./англ.)
|
Целевое использование
|
Правила именования
|
|
Полномочие (Authorization condition)
|
|
Представление полномочия для данного сотрудника
|
Название полномочия
|
|
Должность (Position)
|
|
Представление должности сотрудника организации.
|
Название должности
|
Типы связей представлены в таблице 5.6.2.
Таблица 5.6.2 - типы связей между объектами
|
Тип объекта-источника связи
|
Целевое использование
|
Тип объекта-приемника связи
|
|
Должность (Position)
|
Требует (requires)
|
Предназначена для описания полномочия
|
Полномочие (Authorization condition)
|
.7 Дерево функций
Типы используемых объектов представлены в таблице 5.7.1.
Таблица 5.7.1 - типы объектов
|
Тип объекта рус. (англ.)
|
Символ с именем по умолчанию (рус./англ.)
|
Целевое использование
|
Правила именования
|
|
Функция (Function)
|
|
Описание бизнес-функции в цепочке выполнения
бизнес-процесса.
|
Имя начинается с действия или обозначения процесса,
существенные характеристики которого приводятся далее в имени.
|
Типы связей представлены в таблице 5.7.2.
Таблица 5.7.2 - типы связей
|
Тип объекта-источника связи
|
Тип связи рус. (англ.)
|
Целевое использование
|
Тип объекта-приемника связи
|
|
Функция (Function)
|
Является процессно-ориентированным вышестоящим (Is process-oriented superior)
|
Предназначена для описания типа подчиненности функций
|
Функция (Function)
|
.8 Диаграмма окружения функции (Function allocation diagram)
Типы используемых объектов представлены в таблице 5.8.1.
Таблица 5.8.1 - типы объектов
|
Тип объекта рус. (англ.)
|
Символ с именем по умолчанию (рус./англ.)
|
Целевое использование
|
Правила именования
|
|
Цель (Objective)
|
|
Описание цели процесса
|
Имя начинается с действия или обозначения процесса,
существенные характеристики которого приводятся далее в имени.
|
|
Операционный ресурс (Operating resource)
|
|
Представление используемых ресурсов
|
Имя содержит название ресурса
|
|
Прикладная система (Application system)
|
|
Представление используемых прикладных систем
|
Имя содержит название экземпляра прикладной системы
|
|
Должность (Position
|
|
Представление должности сотрудника организации.
|
Полное название должности
|
|
Письмо (мэйл)
|
|
Письмо по электронной почте
|
Имя содержит название прикрепленного письма, отправленного
по электронной почте
|
|
Носитель информации (Information carrier)
|
|
Представление информационного носителя в материальной форме
|
Имя должно содержать наименование совокупности
|
|
Местонахождение (Location)
|
|
Место,где
находится объект
|
Имя должно содержать координаты места
|
Типы связей приводятся в таблице 5.8.2.
Таблица 5.8.2 - типы связей
|
Тип объекта-источника связи
|
Тип связи рус. (англ.)
|
Целевое использование
|
Тип объекта-приемника связи
|
|
Функция (Function)
|
Поддерживает (supports)
|
Предназначена для описания подчиненности функций
|
Цель (Objective)
|
|
Должность (Position)
|
Отвечает по ИТ за (Is IT responsible for)
|
Предназначена для описания вклада в выполнение функции
данным сотрудником
|
Функция (Function)
|
|
Носитель информации (Information carrier)
|
Имеет
на входе (Provides input for)
|
Предназначена для описания документирования функции
|
Функция (Function)
|
|
Функция (Function)
|
Создает на выходе (Creates output to)
|
|
Носитель информации (Information carrier)
|
|
Прикладная система (Application system)
|
Поддерживает (Supports)
|
Предназначена для описания используемой прикладной системы
|
Функция (Function)
|
|
Функция (Function)
|
Выполняется в (Is executed at)
|
Предназначена для описания места выполнения функции
|
Местонахождение (Location)
|
.9 Диаграмма коммуникаций (Communication diagram)
Типы объектов представлены в таблице 5.9.1.
Таблица 5.9.1 - Типы объектов
|
Тип объекта рус. (англ.)
|
Символ с именем по умолчанию (рус./англ.)
|
Целевое использование
|
Правила именования
|
|
Взаимодействие (communication)
|
|
Представление взаимодействия между орг.единицами
|
Название взаимодействия
|
|
Должность (position)
|
|
Представление должности сотрудника организации
|
Полное название должности
|
|
Организационная единица (organization unit)
|
|
Обозначение отдельного штатного подразделения
|
Полное название подразделения
|
Типы связей представлены в таблице 5.9.2.
Таблица 5.9.2 - типы связей
|
Тип объекта-источника связи
|
Тип связи рус. (англ.)
|
Целевое использование
|
Тип объекта-приемника связи
|
|
Организационная единица (Organizational unit)
|
Посылает (sends)
|
Описание взаимодействия между организационными единицами
|
Взаимодействие (communication)
|
|
Взаимодействие (communication)
|
Получает от (Is received
from)
|
|
Организационная единица (Organizational unit)
|
|
Организационная единица (Organizational unit)
|
Посылает (sends)
|
Описание взаимодействия между организационной единицей и
должностью
|
Должность (position)
|
.10 Модель технических ресурсов (Technical resources model)
Типы объектов представлены в таблице 5.10.1.
Таблица 5.10.1 - типы объектов
|
Тип объекта рус. (англ.)
|
Символ с именем по умолчанию (рус./англ.)
|
Целевое использование
|
Правила именования
|
|
Операционный ресурс (Operating resource)
|
|
Имя содержит название ресурса
|
Используется вид конкретного ресурса
|
Типы связей представлены в таблице 5.10.2
Таблица 5.10.2 - типы связей
|
Тип объекта-источника связи
|
Тип связи рус. (англ.)
|
Целевое использование
|
Тип объекта-приемника связи
|
|
Operating resource type
|
Принадлежит (Belongs to)
|
Описание принадлежности к виду
|
Operating resource class
|
5.11 Дерево продуктов/услуг (Product/Service tree)
Типы используемых объектов представлены в таблице 5.11.1.
Таблица 5.11.1 - типы объектов
|
Тип объекта рус. (англ.)
|
Символ с именем по умолчанию (рус./англ.)
|
Целевое использование
|
Правила именования
|
|
Продукт (Product)
|
|
Представление выпускаемой продукции
|
Имя содержит название продукта
|
Типы связей представлены в таблице 5.11.2.
Таблица 5.11.2 - типы связей
|
Тип объекта- источника связи
|
Тип связи рус. (англ.)
|
Целевое использование
|
Тип объекта- приемника связи
|
|
Продукт (Product)
|
Содержит (subsumes)
|
Описание структуры выпускаемой продукции
|
Продукт (Product)
|
Типы используемых объектов представлены в таблице 5.12.1
.12 Диаграмма рисков (Risk diagram)
|
Тип объекта рус. (англ.)
|
Символ с именем по умолчанию (рус./англ.)
|
Целевое использование
|
Правила именования
|
|
Категория рисков (Risk category)
|
|
Представление рисков
|
Имя содержит полуформальное описание риска
|
|
Риск (Risk)
|
|
|
|
Типы связей представлены в таблице 5.12.2.
Таблица 5.12.2 - типы связей
|
Тип объекта-источника связи
|
Тип связи рус. (англ.)
|
Целевое использование
|
Тип объекта-приемника связи
|
|
Категория рисков (Risk category)
|
Содержит (contains)
|
Описание содержания категории рисков
|
Категория рисков (Risk category)
|
|
Категория рисков (Risk category)
|
Включает в себя (encompasses)
|
|
Риск (Risk)
|
5.13 Диаграмма цепочки добавленного качества (Value-added chain diagram)
Типы объектов представлены в таблице 5.13.1
|
Тип объекта рус. (англ.)
|
Символ с именем по умолчанию (рус./англ.)
|
Целевое использование
|
Правила именования
|
|
Функция (Function)
|
|
Описание бизнес-функции в цепочке выполнения
бизнес-процесса.
|
Имя начинается с действия или обозначения процесса,
существенные характеристики которого приводятся далее.
|
Типы связей представлены в таблице 5.13.2
Таблица 5.13.2 - типы связей
|
Тип объекта-источника связи
|
Тип связи рус. (англ.)
|
Целевое использование
|
Тип объекта-приемника связи
|
|
Функция (Function)
|
Предшествует (Is predecessor of)
|
Описание последовательности выполнения
|
Функция (Function)
|
|
Является процессно-ориентированным вышестоящим (Is process-oriented superior)
|
Описание типа подчиненности
|
|
6. Диаграммы бизнес-модели
.1 Событийно-управляемая цепочка процесса
Рисунок 6.1.1 - Событийно-управляемая цепочка обработки заявки от клиента
(в нотации диаграммы ARIS extended
Event-Driven Process Chain)
.2 Диаграмма организационной структуры ПромТрансИнформ (Organizational chart) представлена на рисунке 6.2
Рисунок 6.2 - Организационная структура ПТИ (в нотации диаграммы ARIS Organizational chart)
6.3 Карта знаний и диаграмма структуры знаний бизнес-аналитика
представлены на рисунках 6.3.1, 6.3.2, 6.3.3
Рисунок 6.3.1 - Карта знаний бизнес-аналитика (в нотации диаграммы ARIS Knowledge map)
Таблица 6.3.1 - Детализация
|
№
|
Наименование детализируемого объекта
|
Тип объекта
|
Наименование модели
|
Тип модели
|
|
1
|
Знания
|
Knowledge category
|
Знания бизнес-аналитика
|
Knowledge structure diagram
|
|
2
|
Умения
|
Knowledge category
|
Умения бизнес-аналитика
|
Knowledge structure diagram
|
Рисунок 6.3.3 - Умения бизнес-аналитика (в нотации диаграммы ARIS Knowledge structure diagram)
Рисунок 6.3.4 - Знания бизнес-аналитика (в нотации диаграммы ARIS Knowledge structure diagram)
6.4 Диаграмма информационных носителей ПТИ представлена на рисунке 6.4
Рисунок 6.4 - Информационные носители ПТИ (в нотации диаграммы ARIS Informational carrier diagram )
.5 Карта полномочий бизнес-аналитика представлена на рисунке 6.5
Рисунок 6.5 - Полномочия бизнес- аналитика (в нотации диаграммы ARIS Authorization map)
.6 Дерево функций для процесса выполнения заказа представлено на рисунке
6.6
Рисунок 6.6 - Дерево функций для процесса выполнения заказа
6.7 Диаграмма окружения функции представлена на рисунке 6.7
Рисунок 6.7. - Окружение функции - Модернизация ИАС «Транспортная работа»
под клиента (в нотации диаграммы ARIS Function
allocation diagram)
.8 Диаграмма коммуникаций представлена на рисунке 6.8
Рисунок 6.8 - Диаграмма коммуникаций - Передача результатов между
отделами (в нотации диаграммы ARIS Communication diagram)
.9 Модель технических ресурсов представлена на рисунке 6.9
Рисунок 6.9 - Технические ресурсы ПТИ (в нотации диаграммы ARIS Technical resources model)
6.10 Дерево продуктов/услуг представлено на рисунке 6.10
Рисунок 6.9 - Продукты и услуги ПТИ (в нотации диаграммы ARIS Product/Service tree)
.11 Диаграмма рисков представлена на рисунке 6.11
Рисунок 6.9 - Диаграмма рисков ПТИ (в нотации диаграммы ARIS Risks diagram)
6.12 Диаграмма цепочки добавленного качества для процесса участия в
конкурсе представлена на рисунке 6.12
Рисунок 6.12 -Процедура цепочки добавленного качества для процесса
участия в конкурсе (в нотации диаграммы ARIS Value-added chain diagram)
7. Документирование бизнес-процесса
При управлении бизнес-процессами, менеджмент компаний сталкивается с тем,
что уровень сложности их управления резко возрастает за счет значительного
увеличения количества объектов в управлении и взаимодействия организационных
структур, а также диверсификации бизнеса, и расширения географии и/или
ассортимента.
В этом контексте документирование деятельности компании несет в себе ряд
важных функций, таких как сохранение базы знаний о различных предметных
областях компании (процессах, организационной структуре, продуктах, полномочиях
и т.д.), повышение прозрачности бизнес-процессов (анализ эффективности
взаимодействия структурных подразделений, участвующих в сквозном процессе),
подготовка процессов организации для внедрения информационных систем.
Документирование деятельности позволяет понять, какие процессы происходят в
организации, кто несет за них ответственность, наделены ли эти ответственные
достаточными полномочиями, обеспечены ли эти процессы достаточным количеством
ресурсов (документирование ПТИ в таблице 7.1.1).
Таблица 7.1.1 - Результаты обследования ПТИ
|
№
|
Должность
|
Отдел
|
Функция
|
Кому подчиняются
|
Входящая информация
|
Исходящая информация
|
|
1
|
Бизнес-аналитик
|
Отдел аналитики
|
Написание БП
|
Гендиректор
|
пожелания клиента, данные обследования ПП клиента
|
ТЗ,
бизнес-процессы
|
|
2
|
Программист
|
Отдел разработки
|
Кодинг ПО
|
Начальник отдела разработки
|
БП,
пожелания клиента
|
ПО (программы)
|
|
3
|
Тестировщик
|
Отдел разработки
|
Тестирование ПО
|
Начальник отдела разработки
|
Готовое ПО
|
Рабочая программа
|
|
4
|
Гендиректор
|
Начальник ПТИ
|
Поиск клиентов, заключение с ними договоров
|
----
|
пожелания клиента,заключенный договор с клиентом
|
Указания начальнику рабработки
|
|
5
|
Директор
|
Начальник ПТИ
|
Соработа вместе с гендиректором
|
Гендиректор
|
пожелания клиента, заключенный договор с клиентом
|
Указания гендиректора
|
|
6
|
Разработчик
|
Отдел разработки
|
Проекти-рование архитектуры ПО
|
Начальник отдела разработки
|
БП,
пожелания клиента
|
Сформированная архитектура
|
|
7
|
Веб-разработчик
|
Отдел разработки
|
Програм. для веб на стороне клиента и сервера,
конфигурирование веб-сервера, верстка
|
Начальник отдела разработки
|
БП, пожелания клиента
|
Конфигурированный сервер,веб-сервер
|
|
8
|
Начальник отдела разработки
|
Отдел разработки
|
-----
|
Гендиректор
|
Задание от директора
|
Указания подчиненным
|
Уточненный список процессов и их владельцев представлен в таблице 7.1.2.
Таблица 7.1.2 - список процессов и их владельцев
|
№
|
Процесс
|
Тип
|
Владелец
|
Входящие подразделения и должностные лица
|
|
1
|
Производство
|
Основной
|
Гендиректор,директор
|
|
2
|
Обеспечение IT
|
Основной
|
Начальник отдела разработки
|
Отдел разработки
|
|
3
|
Контроль качества
|
Основной
|
Тестировщик
|
Отдел разработки
|
|
4
|
Управление организацией
|
Вспомогательный
|
Гендиректор,директор
|
Гендиректор,
директор
|
|
5
|
Хранение данных
|
Вспомогательный
|
Бизнес-аналитик
|
Отдел аналитики
|
Итого, в отделе выделено 5 процессов. Из них 3 основных и 2
вспомогательных.
Документирование процесса производства представлено в таблице 7.1.3.
Таким образом, при внесении необходимых изменений в процесс и его модель, в
выходном документе не будет тех ошибок в логике и расстановке полномочий
структурных подразделений, присутствующих при ручном подходе.
Например, при внесении изменений в процесс, в ARIS новые функции необходимо отразить на соответствующем
БП указанием ответственного подразделения и соответствующего пользователя.
Вручную внесение подобных изменений кропотливый и долгий процесс,
требующий отдельных проверок, что занимает много времени и ресурсов. В ARIS
подобные изменения могут вноситься в течение несколько минут, а процесс генерации
нового документа происходит автоматически.
Таблица 7.1.3 - Процесс производства
|
№
|
Функция
|
Должность
|
Подразделение
|
Входящая информация
|
ИС
|
|
1
|
Согласование условий с заказчиком
|
Директор
|
начальство
|
Условия заказчика
|
-
|
|
2
|
Заключение договора
|
Гендиректор
|
начальство
|
Техническое задание
|
-
|
|
3
|
Информирование сотрудников о заказе
|
Директор
|
начальство
|
Заказ на автоматизация (мэйл)
|
MS Office
|
|
4
|
Описание и документирование БП
|
Бизнес-аналитик
|
Отдел аналитики
|
Комплект документов БП
|
ARIS
|
|
5
|
Проектирование архитектуры ИС
|
Разработчик
|
Отдел разработки
|
Технологические инструкции, данные об архитектуре данных
заказчика, комплект документов БП, требования к ПО
|
-
|
|
6
|
Кодирование ПО
|
Программист или веб-программист
|
Отдел разработки
|
Комплект документов БП, Лицензия на ПО
|
Visual Studio
|
|
7
|
Тестирование ПО
|
Тестировщик
|
Отдел разработки
|
ИС заказчика
|
-
|
|
8
|
Внедрение ИС
|
Разработчик
|
Отдел разработки
|
Заключение по внедрениию ИС
|
-
|
Внесение изменений становится исключительно простым, а формирование
регламентных документов не затягивается до момента, когда каждый новый документ
уже не соответствует действительности.
8. Анализ бизнес-процесса
Анализ процессов следует понимать в широком смысле: в него включается не
только работа с графическими схемами, но и анализ всей доступной информации по
процессам, измерения их показателей, сравнительный анализ и т. д. Существует
как качественный анализов ,так и количественный анализ бизнес-процессов. Начнем
с качественного анализа процесса. Выделение проблемных областей - простейшее
средство качественного анализа процесса. Основное назначение этого способа
анализа состоит в том, чтобы определить направления дальнейшего более
углубленного анализа. На рисунке 8.1 показаны четыре проблемные области.
Первая из них связана с планированием работы, вторая - с выполнением
заказов, третья - со взаимодействием с клиентами, четвертая - со
взаимодействием с кадрами. Приводятся краткие формулировки проблем для каждой
проблемной области.
Выявление проблемных областей осуществляется путем
интервьюирования руководителей и сотрудников, участвующих в рассматриваемом
процессе. Так, на примере рисунке 8.1 проводилось анкетирование сотрудников
ПТИ. Каждый процесс из них выполняют определенные подразделения.
Рисунок 8.1 -Проблемные зоны ПТИ
Полученная таким образом схема процесса может служить предметом для
обсуждения и анализа при выполнении проекта реорганизации процессов. Так,
например, информация о взаимодействие с клиентами может быть рассмотрена более
детально: каков порядок выполнения работ, процесс распределения ролей, порядок
общения с клиентами и т.д.
Именно этот процесс подробно представлен на диаграмме (рисунок 6.1.1).
Так как данный процесс имеет проблемы, это надо реструктурировать.
До модернизации процесс выглядел следующим образом: после заключения
договора с клиентом, гендиректор ПТИ передавал руководство над проектом
менеджеру проекта (рис. 8.2 ).
Но в случае возникновения каких - либо вопросов, менеджер проекта был
вынужден обращаться к гендиректору, чтобы тот отзвонился клиенту и уточнил всю
необходимую информацию. Зачастую это бывало крайне неудобно, так как
гендиректор постоянно в командировках, и не всегда можно было с ним созвонится.
Поэтому менеджеру проекта постоянно приходилось ждать гендиректора, чтобы
уточнить информацию.
Следовательно, сотрудники ждут дальнейших указаний, и работа перестает
двигаться.
Рисунок 8.2 -Процедура выполнение заказа до устранения «узкого места» (в
нотации диаграммы ARIS extended Event-Driven Process Chain)
Теперь процесс выглядит так: после заключения договора с клиентом,
гендиректор ПТИ передает руководство над проектом менеджеру проекта (рис. 8.3).
Передается не только руководство, но и все данные о клиентах (их телефлны
и т.д.).
Теперь ожидать гендиректора не нужно (он может работать спокойно,
заключать новые договоры),а менеджер проекта сам ведет всю работу. В приложении
А должностная инструкция бизнес-аналитика.
Рисунок 8.3 - Процедура выполнение заказа после устранения «узкого места»
(в нотации диаграммы ARIS extended
Event-Driven Process Chain)
Для того, чтобы посчитать, на сколько эффективна модернизация процесса,
рассчитаем KPI (см. глоссарий).
Требования к системе KPI:
· каждый показатель должен быть четко
определен;
· показатели и нормативы должны быть
достижимы: цель должна быть реальной, но в то же время являться стимулом;
· показатель должен быть в сфере
ответственности тех людей, которые подвергаются оценке;
· показатель должен нести смысл;
· показатели могут быть общими для всей
компании, т. е. «привязаны» к цели компании, и конкретными для каждого
подразделения, т.е. «привязаны» к целям подразделения.
Проведем анализ задержек во времени (за какое время
выполнялся заказ до модернизации процесса и после) (таблица 8.1). Расчеты
берутся на один заказ.
Таблица 8.1 - Анализ задержек во времени
|
i
|
Actual, ч
|
Plan,ч
|
qiплан
|
qiфакт
|
Вес, wi
|
qiп*wi
|
qiф*wi
|
|
Уточнение информации у клиента
|
11,00
|
4,00
|
100,00%
|
275,00%
|
0,29878
|
29,88%
|
82,16%
|
|
Написание БП
|
20,00
|
18,00
|
100,00%
|
111,11%
|
0,273762
|
27,38%
|
30,42%
|
|
Кодинг
|
30,00
|
25,00
|
100,00%
|
120,00%
|
0,203252
|
20,33%
|
24,39%
|
|
Тестирование ИС
|
7,00
|
6,00
|
100,00%
|
116,67%
|
0,224205
|
22,42%
|
26,16%
|
|
Внедрение ИС
|
10,00
|
9,00
|
100,00%
|
111,11%
|
0,176441
|
17,64%
|
19,60%
|
|
Интегральная оценка степени достижения цели
|
|
|
|
|
|
|
163,13%
|
|
Плановая интегральная оценка степени достижения цели
|
|
|
|
|
|
100,00%
|
|
Итого эффективность от модернизации (KPI) составляет 63,13%. Данные анализа БП по
результатам отчета анализа модели процесса «БП выполнения заказа (eEPC)»
представлены в таблице 8.2.
Таблица 8.2 - Отчет по результатам анализа модели процесса «БП выполнения
заказа (eEPC)»
|
Наименование показателя
|
Значение показателя по результатам анализа модели на
итерации
|
|
1
|
2
|
|
Number of functions Количество функций
|
9
|
9
|
|
Total allocated application system elements Общее количество используемых
элементов прикладных систем
|
6
|
4
|
|
Application systems В том числе прикладных систем
|
2
|
0
|
|
Application system types В том числе типов прикладных
систем
|
2
|
4
|
|
Computer В том числе компьютеров
|
0
|
0
|
|
Application system class В том числе классов прикладных систем
|
2
|
0
|
|
Functions with application system elements in % Всего функций, поддерживаемых элементами
прикладных систем, в %
|
77,78
|
100
|
|
Functions with application system in %
В том числе поддерживаемых прикладными системами, в %
|
22,22
|
0
|
|
Functions with application system type in %
В том числе поддерживаемых типами прикладных систем, в %
|
33,33
|
100
|
|
Functions with computer in %
В том числе поддерживаемых компьютерами, в %
|
0
|
0
|
|
Functions with application system class in %
В том числе поддерживаемых классами прикладных систем, в %
|
33,33
|
0
|
|
Number of function transitions Количество переходов функций (пар
функций, каждая из которых поддержана хотя бы 1 элементом прикладных систем)
|
8
|
10
|
|
Application system breaks Количество переходов функций с
разрывами элементов прикладных систем
|
6
|
0
|
|
Relationship between application
system breaks/function transitions Коэффициент, отражающий степень интеграции информационных
систем (0…1 ® min)
|
0,75
|
0
|
Для генерации отчетности из системы ARIS используются скрипты отчетности
- программы, набор специальных команд, которые выполняются системой ARIS, и в
результате выполнения которых формируется файл отчета или изменяется наполнение
базы данных ARIS (атрибуты).
Скрипт открывается для редактирования только в ARIS, и применение других
редакторов для его просмотра и изменения невозможно. Помимо простого вывода
информации, содержащейся в базе данных ARIS, с помощью скриптов возможно
проводить анализ всей совокупности моделей и объектов, обрабатывать статистику
и выполнять любые другие действия, необходимые для документирования и анализа
созданных моделей.
Заключение
При
выполнении данной работы была рассмотрена архитектура ARIS,ее достоинства и недостатки, а также другие
методилогии анализа и проектирования (SADT, IDEF0, IDEF3,UML),также
и их плюсы и минусы.
В качестве объекта исследования была выбрана ООО «ПромТрансИнформ»,
занимающаяся автоматизацией предприятий промышленного железнодорожного
транспорта за счет внедрения информационных компонентов программно-технического
комплекса Интегрированной информационной системы управления
«Транспортно-логистический комплекс». В качестве узкого места путем
интервьюривания и общения с сотрудниками было выявлено «узкое место» - слабая
организация рабочего процесса. В ходе исследования было определено, что именно
она мешает слаженности в работе и тормозит процесс выполнения заказов клиентов.
В курсовой работе было построено 9 диаграмм, отображающих всю суть работы ООО
«ПТИ». В них отображена оргструктура ПТИ, документы, риски,
программно-технические средства и т.д.
Также был модернизирован процесс организации рабочего процесса, так как
он напрямую связан с взаимодействием с клиентами.
Как было уже сказано, этот процесс тормозит работу всей компании и
соответственно влияет на прибыль организации. Модернизация этого процесса была
связано с ликвидацией функции «Сообщить о необходимости уточнения информации у
клиента», так как теперь нет необходимости обращаться к гендиректору, чтобы тот
связал с клиентом и уточнил нужную информацию. Теперь всеми организационными
делами проекта (заказа) занимается сам менеджер проекта. Также был посчитан
коэффициент эффективности (KPI),
эффективность составила 63,13%. Результаты анализа процесса представлены в
отчете. Процесс документирования проанализирован в разделе 7.
Глоссарий
1) KPI (кей пи ай) (key performance indicator)
- это ключевой показатель эффективности. Они позволяют оценить эффективность
выполняемых действий. Применять KPI можно как для оценки работы всей компании,
ее отдельных подразделений так и конкретных работников. С помощью системы KPI
можно не только контролировать и оценивать эффективность выполняемых действий,
но и построить эффективную систему оплаты труда.
Список источников
1. Август-Вильгельм Шеер. Бизнес-процессы. Основные понятия.
Теория. Методы
2. Август-Вильгельм Шеер. Моделирование бизнес-процессов
. Войнов И.В., Пудовкина С.Г., Телегин А.И.
Моделирование экономических систем. Опыт построения ARIS-моделей. Монография
. Елиферов В.Г., Репин В.В. Бизнес-процессы.
Регламентация и управление
. Тельнов Ю.В. Реинжиниринг бизнес-процессов (Учебное
пособие)
. Хаммер М, Чампи Дж. Реинжиниринг корпорации -
Манифест революции в бизнесе
. Справочник ARIS 6 methods
. Документы "ПромТрансИнформ" (орг.структура
предприятия, орг.структура ЦКР, должностная инструкциябизнес-аналитика)
9. Брусакова И. А.http://10.242.45.114/cgi-bin/irbis64r_01/cgiirbis_64.exe?Z21ID=&I21DBN=BOOK&P21DBN=BOOK&S21STN=1&S21REF=3&S21FMT=fullwebr&C21COM=S&S21CNR=20&S21P01=0&S21P02=0&S21P03=M=&S21STR=
Информационные системы и технологии в экономике : учеб. пособие для вузов по спец.
"Прикл. информатика" (по обл.) / И. А. Брусакова, В. Д. Чертовской. -
М. : Финансы и статистика, 2007. - 351 с.
Приложение
Утверждаю
ООО “ПромТрансИнформ”
Замятин И.Н
(Фамилия,
инициалы)
(наименование организации) (директор)
.05.2014г.
ДОЛЖНОСТНАЯ ИНСТРУКЦИЯ
БИЗНЕС-АНАЛИТИКА
(наименование учреждения)
08.05.2014г. №20
. Общие положения
1.1.Настоящая должностная определяет права,
ответственность и должностные обязанности бизнес-аналитика ООО “ПромТрансИнформ”
(далее
«предприятие»).
.2.Бизнес-аналитик принимается на работу и увольняется
по приказу руководителя организации по представлению начальника отдела.
.3.Бизнес-аналитик находится в подчинении у начальника
отдела.
.4.На должность бизнес-аналитика принимается лицо с
высшим образованием в области экономики, математического анализа и опыт работы
в аналогичной должности не менее двух лет.
.5.В период отсутствия бизнес-аналитика его
обязанности возлагаются на лицо, назначенное в установленном порядке,
приобретающее должностные права и несущее ответственность за невыполнение или
недолжное выполнение своих должностных обязанностей.
.6.В своей деятельности бизнес-аналитик
руководствуется действующим законодательством, касающимся его деятельности:
-стандартом организации по регламентации, описанию, и
внутреннему аудиту бизнес-процессов;
утвержденным действующим описанием системы
бизнес-процессов организации;
приказами и распоряжениями руководства организации по
вопросам анализа и оптимизации бизнес-процессов, а также касающиеся общей
организации деятельности сотрудников компании;
правилами внутреннего трудового распорядка;
нормами и правилами охраны труда;
правилами пожарной безопасности;
данной должностной инструкцией.
.7.Бизнес-аналитик должен знать:
Федеральный закон от 27 декабря 2002 г. № 184-ФЗ «О
техническом регулировании»;
ГОСТ Р ИСО 9004-2001 «Системы менеджмента качества.
Рекомендации по улучшению деятельности»;
ГОСТ Р ИСО 9001-2001 «Системы менеджмента качества.
Основные положения и словарь»;
ГОСТ Р ИСО 9001-2001 «Системы менеджмента качества.
Требования»;
основы теории организации;
основы управления персоналом;
основы маркетинга и менеджмента;
основы логистики;
основы рыночной экономики;
правовые аспекты бизнес-анализа и управления проектами;
- основы законодательства об интеллектуальной собственности;
внутрикорпоративное бюджетирование и управленческий
учет;
контроллинг;
локальные нормативные акты организации, ее стратегию;
структуру компании, направления ее деятельности,
распределение обязанностей между высшими должностными лицами компании;
действующую утвержденную бизнес-процессную модель
функционирования компании;
современное программное обеспечение;
возможности применения программных продуктов для
выполнения работ по анализу и оптимизации бизнес-процессов;
правила оформления и проведения презентаций;
персональный компьютер на уровне опытного
пользователя;
этику делового общения;
инструкции и положения, определяющие порядок
взаимодействия подразделений компании;
стандарты предприятия по описанию, регламентации и
внутреннему аудиту бизнес-процессов;
приказы и распоряжения руководства организации по
вопросам анализа и оптимизации бизнес-процессов;
передовой зарубежный и отечественный опыт
совершенствования системы менеджмента организаций;
нормы и правила охраны труда;
правила пожарной безопасности.
.8. Бизнес-аналитик должен уметь:
использовать в работе программы графического
отображения аналитической информации;
пользоваться корпоративными базами данных.
. Должностные обязанности
Бизнес-аналитик обязан:
.1.Составлять план интервью и перечень ресурсов,
необходимых для проведения моделирования новых бизнес-процессов.
.2.Подготавливать календарные планы работ по
моделированию, анализу и оптимизации бизнес-процессов и его согласование с непосредственным
руководителем и руководством организации.
.3.Проводить процедуры обследования бизнес-процессов.
.4.Осуществлять моделирование, оптимизацию и анализ
бизнес-процессов с использованием принятых в организации инструментальных
средств моделирования.
.5.Формировать общий аналитический отчет после
проведения анализа бизнес-процессов в виде аналитических таблиц и текстовых
комментариев.
.6.Разрабатывать структуру критериев оценки
эффективности моделируемых бизнес-процессов и функций.
.7.Осуществлять подготовку рекомендаций по внедрению
оптимизированных бизнес-процессов и изменению организационной структуры.
.8.Контролировать процесс внедрения изменений в КИС, в
соответствии с оптимизированными бизнес-процессами.
.9.Осуществлять описание оптимизированных
бизнес-процессов.
.10.Участвовать в написании технического задания на
внесение изменений в КИС в соответствии с оптимизированными бизнес-процессами.
.11.Производить мониторинг доступных источников
информации о существующих методиках обследования и оптимизации бизнес-процессов
для определения недостатков методик, принятых в компании.
.12.Эффективно выполнять все возложенные на него
обязанности.
.13.Своевременно предоставлять достоверную информацию,
касающуюся анализа протекающих в организации бизнес-процессов, их оптимизации.
.14.Контролировать соблюдение плановых сроков и прочих
условий выполнения возложенных на него проектов.
.15.Выполнять иные поручения руководства компании, в
рамках действующей должностной инструкции.
.16.Документировать недостатки методики, существующей
в организации, предлагать способы их устранения и представлять отчеты
непосредственному руководителю.
.17.Проводить презентацию результатов работы по
оптимизации бизнес-процессов.
.18.Принимать участие в проведении обучения
сотрудников компании работе в инструментальной среде моделирования
бизнес-процессов, в условиях оптимизированных бизнес-процессов.
.19.Проходить обучение и повышение квалификации
согласно плану, разработанному в организации.
.20.Предлагать рекомендации по внедрению новых
технологий оптимизации бизнес-процессов.
.21.Разрабатывать демонстрационные материалы,
требующиеся для проведения презентации бизнес-процессов.
.22.Осуществлять обеспечение презентации необходимыми
информационными материалами, программными и техническими средствами.
.23.Обеспечивать выполнение политики компании в
области качества в рамках своей компетенции.
.24.Обеспечивать функционирование в компании системы
управления качеством в рамках своей компетенции.
.25.Самостоятельно определять необходимость и
осуществлять корректирующие и предупреждающие мероприятия в рамках настоящей
инструкции.
.26.Соблюдать все требования, прописанные в
нормативных и методических документах, регулирующих сферу профессиональной
деятельности.
. Права
Бизнес-аналитик вправе:
.1.При возникновении необходимости выезжать в
служебные командировки.
.2.Осуществлять информационное взаимодействие со всеми
должностными лицами всех структурных подразделений организации.
.3.Проводить опрос или интервью, анкетирование
должностных лиц компании с целью сбора необходимой информации, проведения
анализа и оптимизации бизнес-процессов, определения недостатков существующей
системы бизнес-процессов, изучения потребности в ее дальнейшем
совершенствовании.
.4.Запрашивать и получать от должностных лиц компании
необходимые материалы и документацию, относящуюся к протекающим
бизнес-процессам.
.5.Получать в установленном порядке от должностных лиц
компании отзывы (рецензии) на вновь разрабатываемые документы, относящиеся к
бизнес-процессам, в которых они задействованы.
. Ответственность
Бизнес-аналитик ответственен за:
.1.Несвоевременное представление сведений и
отчетности, установленной в организации.
.2.Несоблюдение Правил внутреннего трудового
распорядка.
.3.Несоблюдение правил техники безопасности, охраны
труда и противопожарной безопасности.
.3.Невыполнение или недолжное выполнение своих
должностных обязанностей, предусмотренных настоящей должностной инструкцией.
.4.Предоставление своему руководителю и руководству
организации недостоверной информации о соответствии качества бизнес-процессов,
протекающих в организации, установленным соответствующим показателям.
.5.Разглашение информации, являющейся коммерческой и
иной охраняемой законом тайной.
.6.Причинение предприятию материального ущерба.
Руководитель
структурного подразделения: _____________
__________________
(подпись)
(фамилия, инициалы)
.05.2014г.
С инструкцией ознакомлен,
один экземпляр получил: _____________
__________________
(подпись)
(фамилия, инициалы)