Преподаватель который помогает студентам и школьникам в учёбе.

Реинжиниринг бизнес-процессов ООО «Промтехнологии»

Содержание:

Введение

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

В США это обстоятельство было осознано еще в конце 70-ых годов, когда ВВС США предложили и реализовали Программу интегрированной компьютеризации производства ICAM (ICAM – Integrated Computer Aided Manufacturing), направленную на увеличение эффективности промышленных предприятий посредством широкого внедрения компьютерных (информационных) технологий.

Реализация программы ICAM потребовала создания адекватных методов анализа и проектирования производственных систем и способов обмена информацией между специалистами, занимающимися такими проблемами. Для удовлетворения этой потребности в рамках программы ICAM была разработана методология IDEF (ICAM Definition), позволяющая исследовать структуру, параметры и характеристики производственно-технических и организационно-экономических систем (в дальнейшем, там, где это не вызывает недоразумений – систем).

Цель работы: Изучить теоретические основы структурного подхода к проектированию информационных систем.

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

1. Теоретические основы методологии IDEF

1.1 История возникновения стандарта IDEF

IDEF0, как стандарт, был разработан в 1981 году департаментом Военно-Воздушных Сил США в рамкахпрограммы автоматизации промышленных предприятий, которая носила обозначение ICAM (IntegratedComputer Aided Manufacturing).

Набор стандартов IDEF унаследовал свое название от этой программы (IDEF=ICAM DEFinition). В процессе практической реализации, участники программы ICAM столкнулись снеобходимостью разработки новых методов анализа процессов взаимодействия в промышленных системах.

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

В результате поиска соответствующих решений родилась методология функционального моделирования IDEF0. C 1981 года стандарт IDEF0 претерпел несколько незначительных изменений, в основном, ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 года НациональнымИнститутом По Стандартам и Технологиям США (NIST). [1, с. 62]

1.2 Описание методологий семейства IDEF (ICAM Defenition)

Графический язык IDEF0 удивительно прост и гармоничен. В основе методологии лежат четыре основных понятия: первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника (см. рис. 1) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы.

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

- Верхняя сторона имеет значение «Управление» (Control);

- Левая сторона имеет значение «Вход» (Input);

- Правая сторона имеет значение «Выход» (Output);

- Нижняя сторона имеет значение «Механизм» (Mechanism).
Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

Рисунок 1. Функциональный блок

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

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного. [2, с. 124]

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

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

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

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram). [2, с. 226]

Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

Рисунок 2. Пример процесса декомпозиции

Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором «А0».

В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).

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

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

В процессе декомпозиции, функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок – предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). [4, с. 162]

Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. Важно отметить, что в каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 – модели. Наглядно принцип декомпозиции представлен на рисунке 2. Следует обратить внимание на взаимосвязь нумерации функциональных блоков и диаграмм – каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует.

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

Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение «туннеля» (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из «туннеля») только на этой диаграмме.

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

Рисунок 3. Процесс туннелирования

Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных дуг существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией. [3, с. 241]

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

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

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

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

1.3 Модели AS-IS и ТО-ВЕ

Обычно сначала строится модель существующей организации работы – AS-IS (как есть). На основе модели AS-IS достигается консенсус между различными единицами бизнеса по тому, «кто что сделал» и что каждая единица бизнеса добавляет в процесс. Модель AS-IS позволяет выяснить, «что мы делаем сегодня» перед тем, как перепрыгнуть на то, «что мы будем делать завтра».

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

Признаками неэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (на проведение работы не оказывает влияния ее результат), входу (объекты или информация используются нерационально) и т.д. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) – модели новой организации бизнес-процессов. Модель нужна ТО-ВЕ для анализа альтернативных / лучших путей выполнения работы и документирования того, как компания будет делать бизнес в будущем.

Следует указать на распространенную ошибку при создании модели AS-IS – это создание идеализированной модели. Примером может служить создание модели на основе знаний руководителя, а не конкретного исполнителя работ. Руководитель знаком с тем, как предполагается выполнение работы по руководствам и должностным инструкциям и часто не знает, как на самом деле подчиненные выполняют рутинные работы. В результате получается приукрашенная, искаженная модель, которая несет ложную информацию и которую невозможно в дальнейшем использовать для анализа. Такая модель называется SHOULD_BE (как должно бы быть).

Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, т.е. создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС. Построение системы на основе модели AS-IS приводит к автоматизации предприятия по принципу «все оставить как есть, только чтобы компьютеры стояли», т.е. ИС автоматизирует несовершенные бизнес-процессы и дублирует, а не заменяет существующий документооборот. В результате внедрение и эксплуатация такой системы приводит лишь к дополнительным издержкам на закупку оборудования, создание программного обеспечения и сопровождение того и другого. [4, с. 163]

Иногда текущая AS-IS и будущая ТО-ВЕ модели различаются очень сильно, так что переход от начального к конечному состоянию становится неочевидным. В этом случае необходима третья модель, описывающая процесс перехода от начального к конечному состояния системы, поскольку такой переход – это тоже бизнес-процесс.

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

1.4 Семейство стандартов IDEF

В настоящий момент к семейству IDEF можно отнести следующие стандарты:

IDEF0 — Function Modeling — методология функционального моделирования. С помощью наглядного графического языка IDEF0 изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков — в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы. Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique);

IDEF1 — Information Modeling — методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи; IDEF1X (IDEF1 Extended) — Data Modeling — методология построения реляционных структур (баз данных), относится к типу методологий «Сущность-взаимосвязь» (ER — Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

IDEF2 — Simulation Model Design — методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. В настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (CPN — Color Petri Nets);

IDEF3 — Process Description Capture — Документирование технологических процессов, IDEF3 — методология документирования процессов, происходящих в системе (например, на предприятии), описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 — каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3;

IDEF4 — Object-Oriented Design — методология построения объектно-ориентированных систем, позволяют отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;

IDEF5 — Ontology Description Capture — Стандарт онтологического исследования сложных систем. С помощью методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация;

IDEF6 — Design Rationale Capture — Обоснование проектных действий. Назначение IDEF6 состоит в облегчении получения «знаний о способе» моделирования, их представления и использования при разработке систем управления предприятиями. Под «знаниями о способе» понимаются причины, обстоятельства, скрытые мотивы, которые обуславливают выбранные методы моделирования. Проще говоря, «знания о способе» интерпретируются как ответ на вопрос: «почему модель получилась такой, какой получилась?» Большинство методов моделирования фокусируются на собственно получаемых моделях, а не на процессе их создания. Метод IDEF6 акцентирует внимание именно на процессе создания модели;

IDEF7 — Information System Auditing — Аудит информационных систем. Этот метод определён как востребованный, однако так и не был полностью разработан; IDEF8 — User Interface Modeling — Метод разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интерфейсов в большей степени создают внешний вид интерфейса. IDFE8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интерфейса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем); и, наконец, на деталях интерфейса (какие элементы управления, предлагает интерфейс для выполнения операции);

IDEF9 — Scenario-Driven IS Design (Business Constraint Discovery method) — Метод исследования бизнес ограничений был разработан для облегчения обнаружения и анализа ограничений в условиях которых действует предприятие;

IDEF10 — Implementation Architecture Modeling — Моделирование архитектуры выполнения. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF11 — Information Artifact Modeling. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF12 — Organization Modeling — Организационное моделирование. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF13 — Three Schema Mapping Design — Трёхсхемное проектирование преобразования данных. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF14 — Network Design — Метод проектирования компьютерных сетей, основанный на анализе требований, специфических сетевых компонентов, существующих конфигураций сетей. Также он обеспечивает поддержку решений, связанных с рациональным управлением материальными ресурсами, что позволяет достичь существенной экономии. [5, с. 17]

2. функционально-стоимостной анализ реинжиниринга бизнес-процесса в компании ООО «Промтехнологии»

2.1 Характеристика предприятия ООО «Промтехнологии»

Общество с ограниченной ответственностью «Промтехнологии», располагается по адресу г. Екатеринбург, Сибирский тракт, дом №.8. На отечественном рынке данная организация находится с 2001 года.

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

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

Наряду с этим данное предприятие поставляет высококачественные промышленные шланги, воздуховоды, рукава высокого давления, трубки ПВХ для предприятий Урала и близлежащий городов. ООО «Промтехнологии» располагают собственными производственными линиями электрооборудования в Екатеринбурге, а также конвейеров и подъёмников в Кургане.

Рисунок 4.Структура ООО «Промтехнологии»

2.2 Описание бизнес-процессов в компании ООО «Промтехнологии»

Основные бизнес-процессы в организации представляют главные центры сосредоточения прибыли и затрат. На рисунке 5 схематично представлен производственный процесс в компании ООО «Промтехнологии».

Производство продукции

Оптовая закупка сырья и полуфабрикатов

Техническая проверка, и оснастка, грузовых автомобилей

Хранение материалов и изготовленных изделий

Погрузка и отправка продукции заказчику

Рисунок 5.Производственный процесс ООО «Промтехнологии»

Для проведения процесса реинжиниринга, необходимо детальное представление этапов выполнения основных работ. Для этого в компании ООО «Промтехнологии» был выбран процесс «торговля готовой продукции», на рисунке 6 изображена модель данного бизнес-процесс, описанный с помощью программного обеспечения «Microsoft Visio».

Продолжение рисунка 6

Рисунок 6. Схема бизнес-процесса «торговля готовой продукцией» ООО «Промтехнологии»

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

Для большей наглядности необходимо представить процесс в разрезе отделов компании ООО «Промтехнологии». На рисунке 7 представлена функциональная схема описываемого выше процесса.

ЗАКАЗЧИК	ОТДЕЛ ПРОДАЖ	БУХГАЛТЕРИЯ	ОТДЕЛ ЗАКУПОК	ТРАНСПОРТНЫЙ ОТДЕЛ
Поступил заказ
	Оформление заявки, составление договора
		Выставление счета на оплату
			Формирование заказа по заявке
				Техосмотр транспортного средства
	Согласование даты и времени доставки с заказчиком
	Передача водителю документов
				Выезд автомобиля на склад для погрузки заказа
				Доставка заказа в пункт назначения
				Возврат ТС обратно

Рисунок 7. Функциональная схема бизнес-процесса до реинжиниринга

2.3 Штатное расписание ООО «Промтехнологии»

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

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

В Таблице 2 предоставлен анализ штатного расписания ООО «Промтехнологии».

Таблица 2. Штатное расписание компании ООО «Промтехнологии»

№ п/п	Структурная единица	Кол-во (чел)		Оклад (руб.)		ФОТ		ЧТС (год)		ФРВ (час)
						(год)
1	директор	1		30000		360000		202,70		1776
2	заместитель директора	1		25000		300000		168,92		1776
3	помощник специалиста	1		13000		156000		87,84		1776
4	главный бухгалтер	1		18000		216000		121,62		1776
5	бухгалтер	1		13000		156000		87,84		1776
6	экономист	1		18000		216000		121,62		1776
7	юрист	1		13000		156000		87,84		1776
8	помощник менеджера по закупкам		1		13000		156000		87,84		1776
9	менеджер по закупкам		2		14000		336000		189,19		1776
10	менеджер по продажам		3		14000		504000		283,78		1776
11	водитель-экспедитор		3		18000		648000		364,86		1776
12	автоинженер		2		20000		480000		270,27		1776
13	охранник		2		12000		288000		162,16		1776
14	подсобный рабочий		1		9000		108000		60,81		1776
15	уборщик		2		8000		192000		108,11		1776
	Итого:		23		238000		4272000

На сегодняшний день, компания ООО «Промтехнологии» содержит в штате 23 сотрудников и ведет активную кадровую политику на протяжении последних 12 месяцев.

Месячный фонд оплаты труда составляет 238 000 рублей.

Годовой фонд оплаты труда равен 4 272 000 рублей.

Фонд рабочего времени за 2018 год составил 1776 часов.

2.4 Анализ структурно-элементной модели. Классификация функций

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

Таблица 3. Анализ структурно-элементной модели и классификация функций ООО «Промтехнологии»

№	Наименование функции	Вид функции	Затраты час/год	Затраты на операцию руб./час		Затраты руб./год
1	Оформление заявки	Основная	260	72		18826,6
2	Выставление счета на оплату доставки	Основная	260	68		17752,8
3	Формировка заказа	Вспомогательная	530	68		36188,4
4	Техосмотр автомобиля	Основная	530		103		54828,5
5	Согласование даты и времени доставки	Вспомогательная	480		72		34560
6	Передача водителю документов	Вспомогательная	250		72		18750
7	Выезд автомобиля на склад	Основная	150		207		31050
8	Доставка заказа покупателю	Основная	895		207		185265
9	Возврат автомобиля	Вспомогательная	270		207		55890
	Итого:						453 111,3

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

- согласно проведенной классификации, процесс «оптовая торговля топливом» состоит из 6 основных и 4 вспомогательных функций;

- стоимость реализации данного процесса составляет 453 111,3 руб.

2.5 Анализ целесообразности затрат на функции

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

- 0,5 (относительно меньшая значимость);

- 1 (равнозначность функции);

- 1,5 (относительно большая значимость).

Таблица 4. Анализ целесообразности затрат на функции

Функции	1	2	3	4	5	6	7	8	9	P (0)	P^н (0)	Р (1)	Р^н (1)
1	1	1	1,5	1	1,5	1	1	1	1	10	0,12	10	1,2
2	1	1	1,5	1	1,5	1	1	1	1	10	0,12	10	1,2
3	0,5	0,5	1	0,5	1	0,5	0,5	0,5	0,5	5,5	0,06	5,5	0,33
4	1	1	1,5	1	1,5	1	1	1	1	10	0,12	10	1,2
5	0,5	0,5	1	0,5	1	0,5	0,5	0,5	0,5	5,5	0,06	5,5	0,33
6	0,5	1	1,5	1	1,5	1	0,5	1	1	9	0,12	9	1,08
7	1	1	1,5	1	1,5	1,5	1	1	1	10	0,12	10	1,2
8	1	1	1,5	1	1,5	1	1	1	1	10	0,12	10	1,2
9	0,5	1	1,5	1	1,5	1	0,5	1	0,5	9,5	0,12	9,5	1,14
										79,5		79,5

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

Функции 3 и 5 равнозначны и имеют коэффициент 0,33, доказывает их наименьшую значимость в анализируемом бизнес-процессе: «продажа готового оборудования» в компании ООО «Промтехнологии».

2.6 Функционально-стоимостная диаграмма

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

Для того, чтобы наглядно представить отношение значимости функций и стоимости их реализации в компании ООО «Промтехнологии», была разработана функциональная и стоимостная диаграммы бизнес-процесса «продажа готовой продукции» (Рисунки 8 и 9).

Значимость ь

Зна

Функции

Рисунок 8. Диаграмма значимости функций

Рисунок 9. Диаграмма стоимости функций

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

2.7 Анализ качества выполняемых функций

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

В Таблице 5 представлена информация о методике расчета основных показателей качества функций бизнес-процессов.

Таблица 5. Анализ показателей качества выполняемых функций

Условное обозначение	Наименование коэффициента	Формула расчета	Расшифровка составляющих формулы
К₁	Коэф. использования технических средств управления при выполнении функций	Т_ф/T_р	Т_ф - фактическое время использования технических средств T_р - расчетное техническое время использования технических средств
К₂	Коэф. организации рабочих мест при исполнении функций	К_от/К_о	К_от - кол-во рабочих мест, отвечающих требованиям К_о - общее кол-во рабочих мест
К₃	Коэф. нормирования труда исполнителей функций	В_н/В_о	В_н - время затраченное на выполнение нормируемых работ В_о- общее время
К₄	Коэф. дублирования функций	К_д/К_о	К_д- кол-во дублируемых функций К_о- общее кол-во функций
К₅	Коэф. использования рабочего времени	1- (∑t_n/∑T)	∑t_n - сумма потерь рабочего времени ∑T - ФРВ (год)

= = 0,98; = = 1;

= = 0,87; = = 0,11;

= 1 – ( ) = 0,85.

Согласно рассчитанным, коэффициентам, можно сделать выводы о том, что на предприятии ООО «Промтехнологии»:

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

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

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

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

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

3. Реинжиниринг бизнес-процесса в ООО «Промтехнологии»

3.1 Изменение существующего бизнес-процесса

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

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

Основной бизнес-процесс ООО «Промтехнологии» – «продажа готовой продукции» был оптимизирован, благодаря функционально – стоимостному анализу. На рисунке 10 изображен данный бизнес-процесс, после проведения реинжиниринга, описанный с помощью «Microsoft Visio».

Рисунок 10. Бизнес-процесс после проведения реинжиниринга

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

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

Для большей наглядности необходимо представить новый процесс в разрезе отделов компании ООО «Формула Доставки». На рисунке 11 представлена функциональная схема описываемого выше процесса.

ЗАКАЗЧИК	ОТДЕЛ ПРОДАЖ	БУХГАЛТЕРИЯ	ОТДЕЛ ЗАКУПОК	ТРАНСПОРТНЫЙ ОТДЕЛ
Поступил заказ
	Оформление заявки, составление договора, согласование даты и времени доставки
		Выставление счета на оплату
				Технический осмотр и загрузка автомобиля
	Передача водителю необходимых документов
				Начало движения по маршруту
				Доставка заказа покупателю
				Возврат автомобиля на территорию складского комплекса

Рисунок 11. Функциональная схема бизнес-процесса после реинжиниринга

3.2 Оценка экономической эффективности проведения реинжиниринга в компании ООО «Промтехнологии»

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

Анализ обновлённого процесса компании ООО «Промтехнологии» представлен в таблице 7.

Таблица 7. Анализ структурно-элементной модели после реинжиниринга основного бизнес-процесса

№	Наименование функции	Вид функции	Затраты час/год	Затраты на операцию руб./час		Затраты руб./год
1	Оформление заказа (согласование даты и времени)	Основная	260	72	18826,6
2	Выставление счета на оплату доставки	Основная	260	68	17752,8
3	Формировка заказа	Вспомогательная	530	68	36188,4
4	Передача водителю документов	Вспомогательная	250	72	18750,0
5	Доставка заказа покупателю	Основная	895	207	185265,0
6	Возврат автомобиля	Вспомогательная	270	207	55890,0
	Итого:				Σ 332 602,8

Итогом реинжиниринга процесса «продажа готовой продукции» в компании ООО «Промтехнологии» является:

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

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

- уменьшение степени износа транспортных средства

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

- сокращение стоимости данного процесса на 120 508,5 рублей (с 453 111,3 рублей до 332 602,8 рублей). Этот эффект благотворительно отразиться на ООО «Промтехнологии».

Заключение

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

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

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

Итогом реинжиниринга процесса «продажа готовой продукции» в компании ООО «Промтехнологии» является:

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

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

- уменьшение степени износа транспортных средства;

Список использованной литературы

1. Абдикеев, Н.М.; Данько, Т.П. и др. Реинжиниринг бизнес-процессов; Эксмо; Издание 2-е, испр. - Москва, 2015. - 590 c.

2. Аллин Олег , Зайцев Вениамин Бизнес по правилам и против них. 225 бизнес-идей, 455 практических примеров; Феникс - Москва, 2015. - 416 c.

3. Блинов А. О., Рудакова О. С., Захаров В. Я., Захаров И. В. Реинжиниринг бизнес-процессов; Юнити-Дана - Москва, 2016. - 344 c.

4. Брэнсон Ричард Бизнес в стиле Virgin. Чему вас не научат в бизнес-школе; Манн, Иванов и Фербер - Москва, 2016. - 336 c.

5. Горемыкин В. А. Бизнес-план. Методика разработки. 25 реальных образцов бизнес-плана; Ось-89 - Москва, 2016. - 592 c.

6. Горемыкин В. А. Бизнес-план. Методика разработки. 45 реальных образцов бизнес-планов; Ось-89 - Москва, 2015. - 864 c.

7. Деарлав, Дез Бизнес-путь: Билл Гейтс. 10 секретов самого богатого в мире бизнес-лидера; СПб: Крылов - Москва, 2015. - 208 c.

8. Каргина Е. Н. Учет бизнес-процессов в системе "1С:Бухгалтерия 8.1"; Феникс - Москва, 2016. - 192 c.

9. Крылов Тимофей ИКЕА изнутри. Пример эффективной организации бизнес-процессов (CD + брошюра); Тимофей Крылов - Москва, 2017. - 314 c.

10. Любанова, Т.П.; Мясоедова, Л.В.; Грамотенко, Т.А. и др. Бизнес-план: опыт, проблемы. Содержание бизнес-плана, пример разработки; М.: Приор - Москва, 2016 - 370 c.

11. Маклаков С. В. Моделирование бизнес-процессов с AIIFusion Process Modeler; Диалог-МИФИ - , 2015. - 240 c.

12. Медынский В. Г., Ильдеменов С. В. Реинжиниринг инновационного предпринимательства; Юнити - Москва, 2016. - 416 c.

13. Меркулов Андрей , Мрочковский Николай Бизнес на автопилоте. Как собственнику отойти от дел и не потерять свой бизнес; Альпина Паблишер - Москва, 2015. - 252 c.

14. Мрочковский Николай , Парабеллум Андрей Бизнес. Перезагрузка. Как вывести из крутого пике бизнес, который казалось бы спасти уже невозможно; Манн, Иванов и Фербер - Москва, 2015. - 535 c.

15. Мрочковский Николай , Парабеллум Андрей Бизнес. Перезагрузка. Как вывести из крутого пике бизнес, который казалось бы спасти уже невозможно; Манн, Иванов и Фербер, Эксмо - Москва, 2016. - 248 c.

16. Оголева Л. Н., Чернецова Е. В., Радиковский В. М. Реинжиниринг производства; КноРус - Москва, 2017. - 304 c.

17. Пелих А. С. Бизнес-план, или Как организовать собственный бизнес; Ось-89 - Москва, 2018. - 112 c.

18. Пелих, А.С. Бизнес-план, или Как организовать собственный бизнес. Анализ. Методика. Практикум; М.: Ось-89 - Москва, 2016. - 962 c.

19. Петухова С. В. Бизнес-планирование. Как обосновать и реализовать бизнес-проект; Омега-Л - Москва, 2016. - 176 c.

20. Репин Владимир , Елиферов Виталий Процессный подход к управлению. Моделирование бизнес-процессов; Манн, Иванов и Фербер - Москва, 2015. - 373 c.

21. Репин, В.В.; Елиферов, В.Г. Процессный подход к управлению. Моделирование бизнес-процессов; М.: Стандарты и качество; Издание 3-е, испр. - Москва, 2015. - 408 c.

22. Рис Эрик Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели; Альпина Паблишер - Москва, 2016 - 256 c.

23. Роберт С. Кэмп Легальный промышленный шпионаж. Бенчмаркинг бизнес-процессов: технологии поиска и внедрение лучших методов работы ваших конкурентов; Баланс-Клуб - Москва, 2016. - 416 c.

24. Теличенко В. И., Лапидус А. А., Морозенко А. А. Информационное моделирование технологий и бизнес-процессов в строительстве; Издательство Ассоциации строительных вузов - Москва, 2015. - 144 c.

25. Уткин, Э.А. Бизнес - реинжиниринг; М.: Экмос - Москва, 2016. - 224 c.