Применение процессного подхода для оптимизации бизнес-процессов (Информационные технологии в управлении бизнесом и производством)

Содержание:

ВВЕДЕНИЕ

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

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

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

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

Объектом исследования является ЗАО «ЯСЕНЬ».

Предметом исследования является управление организацией на основе бизнес-процессов.

Цель данной работы – исследование и моделирование бизнес-процессов производственного предприятия.

В соответствии с поставленной целью предстоит решить ряд следующих задач:

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

- рассмотреть информационные технологии в управлении бизнесом и производством;

- изучить методологии описания предметной области;

- рассмотреть состояние рынка средств описания бизнес-процессов и практический опыт описания бизнес-процессов в российских компаниях

- разработать бизнес-процессы для производственного предприятия ЗАО «ЯСЕНЬ».

Проблемами разработки бизнес - процессов, разработки теоретических основ и методологий описания бизнес - процессов, а также практических рекомендаций для разработки бизнес - процессов деятельности компаний занимаются многие исследователи. Например такие как, Дон Делебак, Майкл Хаммер, Джеймс Чампи, Самуйлов К. Е., Серебренникова Н. В., Чукарин А.В ., Яркина Н. В., Д . Марка и К.МакГоуэн, Вендров А. М.

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

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ ИССЛЕДОВАНИЯ И МОДЕЛИРОВАНИЯ БИЗНЕС-ПРОЦЕССОВ ПРЕДПРИЯТИЯ

1.1 Информационные технологии в управлении бизнесом и производством

Бизнес - моделирование (БМ) – это формирование моделей компаний, которые включают описание объектов деятельности и указание связей между ними. В качестве объектов деятельности могут выступать исполнители (отделения, должности), товарно - вещественные ценности (ТМЦ), документы, неструктурированные данные, ИС и иные ресурсы компании, также наружные контрагенты. Требования к создаваемым моделям и их соответственное содержание определяются целями моделирования.

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

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

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

- изготовка к разработке либо внедрению информационной системы.

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

- объектные методики разглядывают моделируемую предметную область как набор взаимодействующих объектов – промышленных единиц. Объект определяется как ощутимая действительность – предмет либо явление, которое имеет верно определяемое поведение. Задачей является выделение объектов, которые составляют компанию, и распределение между ними ответственностей за выполняемые деяния. На сегодня обширно всераспространенной объектной методологией считается ARIS (от англ. Architecture of Integrated Information Systems – архитектура встроенных информационных систем).

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

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

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

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

1. документирование организационной структуры:

- формирование (редактирование) организационных схем;

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

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

- определение главных направлений деятельности и категорий бизнес - действий(метапроцессов);

- многофункциональная декомпозиция действий;

- развитие многофункциональной декомпозиции до уровня бизнес –операций;

- оценка качества декомпозиции, по мере необходимости, внесение изменений;

- сравнение функций и исполняющих их бизнес - единиц – построение матриц ответственности.

3. идентификация документооборота – определение видов и форматов документов, употребляемые в бизнес - действиях компании;

4. документирование ТМЦ (ресурсов) компании, использующихся при выполнении бизнес - функций;

5. описание ИТ - комплекса компании с указанием бизнес -функций, выполняемые с внедрением его программных элемент (ИС, ПО)

6. документирование и подтверждение бизнес - модели:

- формирование отчетов по бизнес - модели в виде диаграмм, таблиц и поясняющего текста;

- распространение документации и проведение презентации;

- сбор замечаний и предложений.

1.2 Методологии описания предметной области

Рассмотренные выше способы исследования предметной области фактически реализуются в специализированных графических языках, который называется нотациями. Обычно, нотации моделирования состоят из блок - схем и правил представления их элемент для описания исследуемого объекта. Неизменное развитие дисциплин разработки программного обеспечения и бизнес моделирования приводит к возникновению новых и улучшению имеющихся нотаций. В дипломной работе более тщательно будут рассмотрены нотации: IDEF0, Нотации Процесс и Процедура, EPC

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

К ее особенностям можно отнести:

- Контекстная диаграмма. Самая верхняя диаграмма, на которой объект моделирования представлен единственным блоком с граничными стрелками. Данная диаграмма называется A-0 (А минус нуль). Стрелки на этой диаграмме показывают связи объекта моделирования с окружающей средой. Диаграмма A-0 устанавливает область моделирования и ее границу. Пример диаграммы A-0 представлен на рис. 1.

Рисунок 1- Диаграмма A-0 нотации IDEF0

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

- Преобладание. Блоки IDEF0 на не контекстной диаграмме должны располагаться по диагонали – от левого верхнего угла диаграммы до правого нижнего в порядке присвоенных номеров. Блоки на диаграмме, которые находятся вверху слева, «доминируют» над блоками, которые находятся внизу справа. «Доминирование» понимается как действие, которое блок оказывает на другие блоки диаграммы. Расположение блоков на листе диаграммы отражает авторское понимание доминирования. В конечном итоге, топология диаграммы показывает, какие функции оказывают большее действие на остальные.

- Выделение 4 видов стрелок. Выделяются следующие виды стрелок: Вход, Выход, Механизм, Управление. Входы преобразуются или расходуются действием, чтобы сделать то, что покажется на его выходе. Управления определяют условия, нужные процессу, чтобы произвести верный выход. Выходы – данные или вещественные объекты, бывшие произведены действием. Механизмы идентифицируют средства, поддерживающие реализацию процесса. В конечном итоге, блок IDEF0 показывает изменение входа в выход с помощью устройств с учетом управляющих действий. Используемые графические знаки представлены в таблице 1.

Таблица 1- Используемые графические символы

Название	Графический символ	Описание
Процесс		Процесс обозначается прямоугольным блоком. Внутри каждого блока помещается его имя и номер. Имя должно быть активным глаголом, глагольным оборотом или отглагольным существительным. Номер блока размещается в правом нижнем углу. Номера блоков используются для идентификации на диаграмме и в соответствующем тексте.
Стрелка
Туннелированная стрелка
Внешняя ссылка
Междиаграммная ссылка
Процесс-ссылка
Сноска
Текст		Комментарий без сноски.Элемент может быть использован на диаграммах процессов в любых нотациях.

Пример диаграммы процесса в нотации IDEF0 представлен на рис. 2.

Нотации Процесс (Basic Flowchart в Майкрософт Visio) и Процедура (Cross Functional Flowchart в Майкрософт Visio) употребляются для представления способа (сценария) выполнения задачи и разрешают задать причинно-следственные связи и временную последовательность реализации действий процесса. Нотации поддерживают декомпозицию на подпроцессы, также как и нотация IDEF0.

Различие междунотациями Процесс и Процедура состоит в том, что дополнительно к графическим элементам, применяемые в нотации Процесс, в нотации Процедура употребляются дорожки (Swim Lanes), обозначающие организационные единицы – исполнителей действий процесса. Это позволяет повысить наглядность диаграммы. Используемые графические элементы представлены в таблице 2.

Рисунок 2- Диаграмма процесса нотации IDEF0

Таблица 2- Используемые графические элементы

Название	Графический символ	Описание
Действие
Дорожки (диаграмма Процедура)
Этап
Событие
Решение
Связь предшествования
Поток объектов	.

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

Пример диаграммы в нотации Процесс приведен на рис.3., а диаграммы в нотации Процедура – на рис. 4.

Рисунок 3- Пример диаграммы в нотации Процесс

Рисунок 4-. Пример диаграммы в нотации Процедура

Нотация EPC (Event-DrivenProcessChain – цепочка действий, управляемые событиями) была разработана в 1992 г. Институтом информационных систем при Саарском институте (Германия) в рамках научно-научного проекта, финансировавшегося компанией SAPAG. Ведомую роль в проекте сыграл управляющий Института врач Август-Вильгельм Шеер (учредитель организации IDS Scheer, выпускающий ПО семейства ARIS). Метод EPC стал частью изготовленной им мысли ARIS (Architecture of Integrated Information Systems – архитектура интегрированных информационных систем).

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

Диаграмма EPC представляет собой упорядоченный граф событий и бизнес-функций. Пример данный диаграммы приведен на рис.5.

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

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

Рисунок 5- Пример диаграммы EPC

Рисунок 6-Операторы в нотации EPC

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

Для построения диаграмм бизнес-действий в методике ARIS применяется расширение нотации EPC – extended EPC (eEPC), но на данный момент под EPC нередко подразумевают уже расширенную нотацию. В eEPC не считая рассмотренных нами объектов – функций, событий, связей (стрелок) и операторов – употребляются следующие объекты.

- организационная единица (англ. organizational unit) служит для обозначения различных организационных звеньев компании;

- документ (англ. document) отражает истинные носители информации, например картонный документ;

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

- кластер информации (англ. cluster) употребляется для сотворения моделей данных и характеризовает данные как набор сущностей и связей меж ними.

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

Рисунок 7- Пример использования нотации eEPC

Нотация EPC представляет собой простое, наглядное и эффективное средство моделирования, позволяющее в виде последовательности событий и функций описывать сложные бизнес-процессы. Она применяется в таких распространенных программных продуктах, как SAP и ARIS. К недостаткам EPC следует отнести отсутствие строго определённого синтаксиса и семантики. Диаграммы EPC не имеют определенного формального языка, что может привести к построению логически некорректных диаграмм и затрудняет переносимость диаграмм EPC между различными программными продуктами.

1.3 Состояние рынка средств описания бизнес-процессов и практический опыт описания бизнес-процессов в российских компаниях

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

ВЫБОР ИНСТРУМЕНТАРИЯ И МЕТОДОЛОГИИ ДЛЯ ОПИСАНИЯ ПРОЦЕССОВ

Часто данной теме в принципе не уделяется никакого внимания при принятии решения по описанию бизнес-процессов. При всем этом предполагается (совсем неверно), что нет различия в том, какое ПО и какую методологию применять.

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

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

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

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

Может быть, поэтому, что данный вопрос кажется чрезвычайно узкоспециальным, ему совершенно не уделяют внимания, и совершено зря. Имеющиеся подходы по описанию бизнес-процессов, как и существующее ПО, за редким исключением, специализированы и плохо подступают для решения тех задач, для которых они не были предусмотрены вначале. К примеру, компания решила повысить свою продуктивность, и для этого собирается сделать взаимосвязанную непротиворечивую модель бизнеса всей компании, описав систему бизнес-процессов, любой из которых связан товарищ с другом плодами работы, каждый участник процесса имеет характеристики KPI, каждое отделение компании имеет планы и бюджеты, нацеленные на достижение единых стратегических задач. В этом случае решение применять методике и программное обеспечение, которые были разработаны, сначала, для описания алгоритмов и взаимосвязей операционного уровня будет для компании очень трудно, недешево и долго. И поэтому, отдав решение этого вопроса на откуп узеньким (техническим) спецам, компания испытывает судьбу получить в итоге положение дел не очень приятную: израсходованы значимые денежные ресурсы, время, усилия, а полученный формальный итог не дает ожидаемого эффекта.

Поверхностный изучение интернета указывает, что эта тема (выбор методике и инструментария) недостаточно освещена (изучение META Group не много того, что больше нацелен на IT-решения, так к тому же практически не учитывает особенностей Российского рынка, разглядывает лишь обычных уполномоченных лиц сложившегося западного рынка). Более нередко видятся статьи сопоставления методологий ARIS и IDEF. Иной самой популярной темой является перечисление мощных и слабых сторон (обычно методологий) без учета того, применительно к какой задачке эти качества анализируются. Становится несколько удивительно: неуж-то, к примеру, грузоподъемность грузового автомобиля постоянно является бесспорным преимуществом, вне зависимости от того, для чего я выбираю машину?

Детализированный изучение применяемого в целях описания бизнес-действий инструментария (методологий, программного обеспечения) — это тема некоторого изучения. Не претендуя на глубину, дадим общую характеристику товаров в свете обрисованных выше задач:

- CA ERwin Data Modeler (до этого называвшийся AllFusion Data Modeler, BPwin). Более успешно реализована возможность описания взаимосвязанных трудных моделей, задачки описания алгоритмов и последовательности действий реализованы приметно слабее. Обыкновенные (немногословные) нотации описания. Трудно, или в принципе никак не реализуются доп задачки (увязка задач и процессов, создание дерева характеристик, проведение имитационного моделирования);

- ARIS (набор программных обеспечений, модулей компании IDS Scheer). Само заглавие (Architecture of Integrated Information Systems) гласит о том, что ПО вначале было нацелено на решение задачки описания алгоритмов и последовательности действий. Все другое в ARIS тоже можно делать, но это будет получаться чрезвычайно тяжело. Для описания бизнес-действий придётся применять огромное число моделей (в ARIS их более 80, и количество их растет) довольно трудной семантики, в которой путаются даже более ярые адепты. Без огромного опыта и существенного переосмысления основ методике воплотить трудные описания взаимосвязанных моделей тяжело;

- Corporate Modeler (Casewise Systems) во многом является английским более молодым аналогом ARIS — не по методологии и решениям, но по самим идеям1 ПО. Кроме того, нацелено на помощь в описании бизнес-процессов для следующей разработки программного обеспечения. Однако стоит оно в среднем дешевле;

- iGrafx Enterprise Central (отделение Corel Inc) пока наименее популярное в России, но очень привлекательное решение из Канады. Включает в себя целый набор модулей по описанию, моделированию процессов, приложения по планированию и управлению качеством управлением рисками. Значительным ее минусом является ее нераспространённость;

- Business Studio (ГК «Современные технологии управления»). Более популярная российская разработка из семейства изучаемого ПО. Пожалуй (на наш личный взор), успешно совмещает (как это может быть) некоторые более полезные возможности BPwin и ARIS, кое-чем напоминая по своему решению iGrafx (но не по стоимости). Если для заказчика принципиально соотношение стоимость/возможности, наверняка, это лучший выбор для российских компаний. Имеет один недочет, в связи с тем, что чрезвычайно плотно интегрирована с MS Office (Word, Excel, Visio), а поэтому все шероховатости этих решений автоматически переносятся и на Business Studio.

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

- Из умной книжки (ведь «еще Портер писал что-то про это, а у нас этого нет!») либо во время обучения, к примеру, на ставшей на данный момент престижной степени МВА;

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

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

В этом случае, итоговая задачка звучит как-то так: «нам нужно обрисовать наши бизнес-процессы, давайте находить спеца по описанию и оптимизации бизнес-процессов». Если начать интересоваться, а зачем, то ответы, вероятнее всего, будут логически чрезвычайно не связанными с итоговой задачей. А далее вероятны два принципно различных варианта.

В первом исполнитель без излишних вопросов, которые нервируют заказчика, добросовестно приступает к описанию процессов. Всех, либо тех какие ему предложат: «давайте начнем с процесса выставления подрядным организациям и возврата подтверждающих документов, об этом чрезвычайно просит бухгалтерия». Обычно, при всем этом употребляются знакомые и простые нотации описания процедур (либо кросс-чарт, либо EPC). Работа идет чрезвычайно споро, без излишних вопросов (описываем, что произнесут либо как есть). Однако в итоге итог выходит незамудреным. Как говорят спецы ИТ: «при попытке заавтоматизировать бардак — выходит автоматический бардак», с процессами выходит еще ужаснее — бардак в квадрате. Описанные процессы, которые описаны конкретно так, как это случается в жизни, и на бумаге трудны и запутанны. Последующим шагом исполнитель может попробовать что-или улучшить (как досадно бы это не звучало, называют это звучно — улучшить). Однако при этом он, обычно, учитывает точку зрения ограниченного круга лиц, не учитывает всех вероятных связей с другими процессами, особенностей корпоративной культуры, и потому, по сути, не улучшает ничего. Однако при этом израсходовано существенное число времени и ресурсов. После чего, вероятнее всего, заказчиком принимается решение, что описание действий не помогло.

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

Вдруг просто начинает выясняться ряд особенных деталей, которые, по сути, неприятны заказчику:

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

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

- Бизнес значительно подвержен наружным и/либо внутренним рискам;

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

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

Столкнувшись со всеми описанными выше вопросами, когда необходимо не просто обрисовать процессы — нужно поменять значительную часть бизнеса, случается, что не у каждого заказчика располагается внутренний мотив для этого. В этом случае, для исполнителя принципиально будет поначалу найти конкретно его — данный несчастный мотив. В противном случае работа по описанию действий может просто не начаться. Отлично это либо плохо? Если не искать «вселенской правды», то, наверняка, отлично, при этом для обеих сторон:

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

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

Однако, естественно, это быстрее удовлетворительное решение, минимизирующее сиюминутные опасности, но не приносит никому выигрышей на более продолжительном горизонте. Более удачное решение просит несколько большего, чем умение обрисовывать бизнес-процессы. В любом случае, описание бизнес-процессов — это задачка, требующая не только опыта и знаний от непосредственного исполнителя, но и знаний, готовности и желания пройти данный сложный путь от заказчика.

Как можно не совершать описанные ошибки? Все просто. Необходимо так не поступать. Ниже приведен перечень задач, которые стоит решить, до того как будут выделены главные средства (ресурсы) и приобретено особое ПО, покажутся новые люди и нарисуют 1-ые «квадратики», напишут 1-ые строчки порядков. Потому что это лишь самое начало вероятного проекта по изменениям, то никто нам не мешает израсходовать мало выше, чем это принято, времени, и подумать о том, что и как компания желает получить и сколько она готова заплатить.

Для этого стоит, по меньшей мере, сделать последующее:

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

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

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

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

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

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

ГЛАВА 2. РАЗРАБОТКА БИЗНЕС – ПРОЦЕССОВ ДЛЯ ПРОИЗВОДСТВЕННОГО ПРЕДПРИЯТИЯ ЗАО «ЯСЕНЬ»

2.1 Организационно-экономическая характеристика предприятия

ЗАО «ЯСЕНЬ» было зарегистрировано 31 августа 2010 года и специализируется в области технического обслуживания, ремонта офисных машин и вычислительной техники.

ЗАО «ЯСЕНЬ» занимается комплексным информационно-техническим обеспечением как предприятий, так и отдельных физических лиц.

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

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

- восстановление рабочего состояния операционной системы и очистка от вирусов;

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

- ремонт блоков питания, сетевых адаптеров, материнской платы;

- модернизация персонального компьютера или ноутбука;

- восстановление BIOS в стационарном компьютере или ноутбуке;

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

Также ЗАО «ЯСЕНЬ» выполняет работы по ремонту лазерных принтеров, копировальных аппаратов. При проведении ремонтных работ выполняются работы по осмотру техники, тестированию, проверке работоспособности, чистки без разборки.

Организационно-штатная структура ЗАО «ЯСЕНЬ» приведена в приложении 1.

Как видно из приложения, управляет ЗАО «ЯСЕНЬ» генеральный директор, в подчинении у которого находится главный бухгалтер, начальник службы обеспечения, инженер отдела кадров и начальник службы технического обслуживания.

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

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

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

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

Среди клиентов ЗАО «ЯСЕНЬ» пользуется спросом программа для удаленного сетевого управления «Web Smart Device Monitor», схема которой приведена на рисунке 2.

Рисунок 8 – Схема удаленного мониторинга копировальной техники и печатающих устройств с помощью программы «Web Smart Device Monitor»

Программа для удаленного сетевого управления «Web Smart Device Monitor» позволяет вести мониторинг и контроль сетевых многофункциональных устройств, принтеров, сканеров и других устройств.

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

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

Отдел информационных технологий ЗАО «ЯСЕНЬ» выполняет следующие задачи:

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

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

- подготовке проектов договоров на обслуживание информационных систем;

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

Администратор ЗАО «ЯСЕНЬ», осуществляет:

- администрирование серверов в рамках полномочий отдела;

- поддержку работоспособности ЛВС;

- установку и настройку АРМ пользователей;

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

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

Таким образом, ЗАО «ЯСЕНЬ» оказывает услуги по ремонту, диагностике компьютерной и копировальной техники, выполняет замену запасных частей. В своей деятельности использует специализированное программное обеспечение.

2.2 Разработка бизнес – процессов организации

В таблице 3 приведён сравнительный анализ подходов описания процессов.

Таблица 3-Сравнительный анализ подходов описания процессов.

Критерий сравнения	«Ускоренное» описание бизнес-процессов	«Полное» описание бизнес-процессов
Степень субъективности	Высокая	Незначительная
Полнота описания деятельности организацией	Фрагментарное описание	Полное описание
Длительность выполнения проекта	2-3 месяца	6-12 месяцев
Корректность полученных моделей процессов	40-80% соответствия реальным процессам	80-90% соответствия реальным процессам
Степень участия руководителей и сотрудников организации в проекте	Незначительная	Высокая
Трудоемкость	Средняя	Высокая
Степень риска неудачи проекта (при наличии поддержки руководства)	30-70%	0%
Степень риска неудачи проекта (при отсутствии поддержки руководства	80-100%	20-30% (получены формальные результаты)
Возможность исполнения результатов проекта (моделей)	На 20-40%	На 80-90%

Таблица 4-Процессы верхнего уровня и их владельцы

Процесс	Тип	Владелец	Участвующие подразделения и должностные лица
Управление компанией	Упр.	Генеральный директор	Ген. Директор, Директор по снабжению, Директор по производству, Директор по продажам, Директор по транспорту, Директор по общим вопросам, Финансовый директор, Директор по персоналу, Отдел развития, Юридический отдел.
Управление снабжением	Осн.	Диретор по снабжению	Отдел снабжения, Менеджер по закупке сырья и материалов, аналитик по закупке сырья и материалов, секретарь.
Производство	Осн.	Начальник цеха.	Цех1, Цех2.
Управление продажами	Осн.	Начальник отдела продаж.	Отдел трейд-маркетинга и продвижения, Служба управления продажами, Отдел маркетинга, Менеджер по продажам, Аналитик по продажам.
Управление транспортировками	Осн.	Начальник транспортного отдела	Транспортный отдел.
Управление финансами	Всп.	Начальник Финансового отдела	Финансовый отдел, планово-экономический отдел, бухгалтерия, отдел ИС.
Управление персоналом	Всп.	Начальник отдела кадров	Отдел кадров.
Управление документооборотом	Осн.	Секретариат	-

Таблица 5-Список детализации процессов верхнего уровня на набор внутренних подпроцессов компании ЗАО «Ясень»

Бизнес-процесс	№ о/п	Подпроцесс (операция)
Управление снабжением (заказами)	1.1	Корректировка предложений по заказам и рассылка поставщикам
	1.2	Формирование предложений по заказу
Производство	2.1	Планирование производства
	2.2	Подготовка и наладка оборудования
	2.3	Приёмка товара
	2.4	Переработка
	2.5	Сдача продукции на склад
Управление продажами	3.1	Поиск клиентов
	3.2	Заключение договора на продажу продукции
	3.3	Корректировка предложений по заявкам
	3.4	Выполнение обязательств по договору
	3.5	Контроль счетов
Управление транспортировками	4.1	Перевозка продукции
	4.2	Отгрузка продукции
	4.3	Проверка сопутствующих документов
Управление документооборотом	5.1	Контроль отчетов
	5.2	Контроль прайсов
	5.3	Контроль основных документов
Управление бухгалтерской деятельностью	6.1	Формирование кассовой книги
	6.2	Начисление з/п
	6.3	Составление стандартизированного отчёта (ежемесячно, ежегодно)
Управление финансами	7.1	Получение вознаграждения от поставщика
	7.2	Формирование бюджета
	7.3	Составление детального плана продаж
Управление персоналом	8.1	Прием на работу
	8.2	Перевод сотрудников
	8.3	Обучение сотрудников
	8.4	Увольнение
Управление ремонтами	9.1	Ремонт и техобслуживание оборудования
	9.2	Ремонт и обслуживание теплоэнергетических сетей
И др.	-	-

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

Таким образом, в условиях единого координирования значимость документооборота имеет особую роль.

Рассмотрим документы которые используются на ЗАО «Ясень».

Таблица 6- Процесс и используемые документы

Наименование подпроцесса (операции)	Используемые и формируемые документы
Планирование производства	- План производства - Заявка на продукцию - Журнал планов производства

Таблица 7-Входящие документы

Документ	Откуда поступает	Срок поступления	Способ получения
Заявка на продукцию	Менеджер по продажам	В 16-00	Через сотрудников компании, эл. почта

Таблица 8-Исходящие документы отдела

Документ	Куда поступает	Требования к срокам передачи	Способ получения
нет	нет	нет	нет

Таблица 9-Внутренние документы

Документ	Ответственный за ведение	Способ ведения
План производства на день	Главный технолог	Бумажный документооборот
Журнал планов производства	Главный технолог	Бумажный документооборот

Таблица 10-Входящие товарно-материальные ценности

Наименование	Откуда поступает	Сопровождающие документы
нет	нет	нет

Таблица 11-Исходящие товарно-материальные ценности

Наименование	Куда поступает	Сопровождающие документы
нет	нет	нет

На основе полученного описания элементов бизнеса-процесса можно составить регламент процесса «Планирование производства».

На основе регламента создадим диаграмму в нотации Cross Functional Flowchart, используя пакет Microsoft Visio, для детального описания бизнес-процесса представленную на рис.9.

Рисунок 9- Детальное описание бизнес-процесса «Планирование производства»

Подпроцесс «Подготовка и наладка оборудования».

Таблица 12-Процесс и используемые документы

Наименование подпроцесса (операции)	Используемые и формируемые документы
Подготовка и наладка оборудования	- Журнал учёта выполненных работ по подготовке и наладке оборудования - Копия из журнала учёта выполненных работ по подготовке и наладке оборудования

Таблица 13-Входящие документы

Документ	Откуда поступает	Срок поступления	Способ получения
нет	нет	нет	нет

Таблица 14-Исходящие документы отдела

Документ	Куда поступает	Требования к срокам передачи	Способ получения
Копия из журнала учёта выполненных работ по подготовке и наладке оборудования	Бухгалтер	В конце рабочего дня	Лично

Таблица 15-Внутренние документы

Документ	Ответственный за ведение	Способ ведения
Журнал учёта выполненных работ по подготовке и наладке оборудования	Начальник смены	Бумажный документооборот

Таблица 16-Входящие товарно-материальные ценности

Наименование	Откуда поступает	Сопровождающие документы
нет	нет	нет

Таблица 17-Исходящие товарно-материальные ценности

Наименование	Куда поступает	Сопровождающие документы
нет	нет	нет

На основе полученного описания элементов бизнеса-процесса можно составить регламент процесса «Подготовка и наладка оборудования».

Рисунок 10- Детальное описание бизнес-процесса «Подготовка и наладка оборудования»

По результатам исследования бизнес-процессов компании, а именно бизнес-процесса производства было выявлено, что в компании на данный момент используется в большей части бумажный документооборот. Так же в компании нет никакого программного продукта, позволяющего улучшить производственный процесс и сократить издержки производства. На основании выполненной постановки задачи на первоначальном этапе разработки АРМ специалиста по обработке заявок клиентов ЗАО «Ясень». разработаем архитектуру автоматизированного рабочего места, чтобы повысить прибыльность предприятия (рисунок 11).

Рисунок 11 – Иерархическая схема модулей АРМ специалиста по обработке заявок клиентов ЗАО «Ясень».

Описание модулей программного средства:

- fclient вызывается с главного меню для внесения изменений по клиентам предприятия;

- fsmeta вызывается с модуля fZakaz для внесения изменений в сметы формирования себестоимости оказания услуг;

- fComplect вызывается с главного меню для внесения изменений в оборудование для выполнения заказа;

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

- fmain для внесения изменений в главной форме программы;

- fpassword для внесения изменений в форму для авторизации в программе;

- fZakaz вызывается с главного меню для внесения изменений в форму заказа;

- fsearch вызывается с главного меню для внесения изменений в форму Поиска;

- pStatAnalyse вызывается с главного меню для построения модели.

На основании разработанной архитектуры АРМ специалиста по обработке заявок клиентов ЗАО «Ясень». приведенной на рисунке 11 в системе будут автоматизированы следующие функции:

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

- ведения учета заказов с формированием сметы оборудования или работ и бланка заказа для клиента;

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

- ведение базы выполняемых работ для формирования себестоимости и бланка заказа для клиентов;

- выполнять моделирование процесса оказания услуг.

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

На рисунке 12 изображена разработанная функциональная схема АРМ.

Рисунок 12 – Функциональная схема АРМ

ЗАКЛЮЧЕНИЕ

В результате выполнения курсовой работы были сделаны следующие основные выводы.

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

Проанализировано состояние рынка средств описания бизнес-процессов. Рассмотрены программные продукты по описанию бизнес – процессов.

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

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

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

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

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

2. происходит оценка работы коллектива;

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

4. все пакеты документов будут формироваться автоматически;

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

Предложение по внедрению программы было предложено в ЗАО «Ясень», сотрудники заинтересованы в ведении новшеств, но на данный момент в компании устанавливается новое дорогостоящее оборудование. Компания рассматривает будущее внедрение программы.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Андерсен Б. Бизнес-процессы. Инструменты совершенствования / Б. Андерсен ; [пер. с англ. С. В. Ариничева ; под науч. ред. Ю.П. Адлера]. - 5-е изд. - М. : Стандарты и качество, 2016
2. Вендров А. М., Проектирование программного обеспечения экономических информационных систем / А.М. Ведров - М.: Издательство « Финансы и статистика ». 2015
3. Глазунов А. В. Диалоги консультанта с руководителем компании. Высшему руководству о процессном подходе/ А.В. Глазунов - Н. Новгород.: Приоритет, 2014
4. Делебак. Д. Бизнес - модели. Принципы создания процветающей организации/ Д. Делебак - М.: Издательство «Издательский дом Гребенникова ». 2014
5. Елиферов В. Г. Бизнес-процессы: Регламентация и управление / В.Г. Елиферов, В. В. Репин - М.: Инфра-М, 2014
6. Ивлев В.А. ABIS. Информационные системы на основе действий / В.А. Ивлев, Т.В. Попова. - М.: 1С-Паблишинг, 2015
7. Ковалёв, С. М., Выбор бизнес-процессов для оптимизации / С. М. Ковалёв, В. М. Ковалёв // Консультант директора. – 2016
8. Ковалёв, С. М. Современные методологии и стандарты описания бизнес-процессов: преимущества, недостатки и области применения / С. М. Ковалёв, В. М. Ковалёв // Справочник экономиста. – 2015
9. Козлов, А. С. Проектирование и исследование бизнес-процессов/ А. С. Козлов. - М.: Флинта: МПСИ, 2014
10. Калянов Г.Н. Моделирование и автоматизация бизнес-процессов: ученое пособие для студ. вузов, обуч. по спец. 080801 "Прикладная информатика" и др. экон. спец. / Г. Н. Калянов. - М. : Финансы и статистика, 2016
11.  Кремсер В. Управление проектами - путь к управлению бизнес-процессами? // Методы менеджмента качества.—2014
12. Марка Д. Методология структурного анализа и проектирования SADT / Д. Марка и К.МакГоуэн. – М.: Метатехнология, 2014
13. Основы формальных методов описания бизнес – процессов / К.Е. Самуйлов. - М.: РУДН , 2014
14. Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес – процессов/ В.В.Репин, В.Г. Елиферов - М.:РИА «Стандарты и качество»,2015
15. Теличенко В.И. Информационное моделирование технологий и бизнес-процессов / В.И. Теличенко, А.А. Лапидус, А.А. Морозенко. - М.: Издательство Ассоциации строительных вузов, 2016
16. Трояновский В.М. Информационно-управляющие системы и прикладная теория случайных процессов / В.М. Трояновский. - М.: Гелиос АРВ, 2014
17. Шлыкова Ольга Владимировна Интернет-Ресурсы И Услуги: Учебная Программа По Специальности 351400 «Прикладная Информатика (В Менеджменте), Квалификация «Информатик-Менеджмер»: моногр. / Шлыкова Ольга Владимировна. - Москва: Гостехиздат, 2017.
18. Система автоматизации документооборота [Электронный ресурс] // Википедия, свободная энциклопедия. –URL: ru.wikipedia.org (Дата обращения: 08.07.2018)
19. Система бизнес - моделирования Business Studio. [Электронный ресурс] // Модели бизнес – процессов предприятия. URL:http://www.businessstudio.ru. (Дата обращения: 08.07.2018)
20. Состояние ранка средств описания бизнес – процессов и практический опыт описания бизнес процессов в российских компаниях. [Электронный ресурс] // Компания Process – expert. Управление бизнес- процессами URL:http://www. process.siteedit.ru/page49.html. (Дата обращения: 08.07.2018)

Приложения

Организационная структура