Модель бизнес-процесса УУПП 'Автоконтакт' ВОС

ВВЕДЕНИЕ

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

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

Это будет первым этапом на пути полной автоматизации процесса управления в соответствии с мировыми стандартами (например, MRP, MRP II, ERP).

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

Объектом данного исследования является УУПП “Автоконтакт” ВОС.

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

Цель - совершенствовать бизнес-процесс на основе разработки и анализа его модели.

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

1. Выявить проблемы автоматизации в российских условиях и установить их причины.

2. Исследовать сущность бизнес-процессов и основные качественные и количественные критерии их оптимизации.

3. Провести сравнительный анализ методологий моделирования Б-П и обосновать выбор программного средства.

4. Разработать список мероприятий по организации процесса моделирования на УУПП “Автоконтакт” ВОС.

5. Разработать модель бизнес-процесса УУПП “Автоконтакт” ВОС.

При решении поставленных задач были использованы методы: системного анализа и синтеза, методы графического моделирования бизнес-процессов.

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

.1 Проблемы автоматизации в российских условиях, выявление причин

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

Основная причина этого заключается в значительном отставании менеджмента российских компаний от западных. Именно поэтому, 50% попыток внедрения западных корпоративных информационных систем (КИС) не доходит до конца, а в остальных 50% случаев хорошим результатом является внедрение хотя бы нескольких модулей [32]. Анализируя опыт практиков внедрения КИС [8,13,19] была выявлена, следующая причина: под видом внедрения западной компьютерной системы, фактически, проводится полная реструктуризация управления. Причем делается это неосознанно: персонал как бы учится программе, а на самом деле ему задаются совершенно другие форматы поведения и управленческой отчетности. Но поскольку происходящее не осознается правильно, то усилия не направлены должным образом. А такие усилия необходимы, именно потому, что процесс реструктуризации управления предприятием на порядок сложнее, чем перевод менеджмента на компьютерные технологии.

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

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

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

Таким образом, приходится согласиться с большинством авторов, что для достижения ощутимых результатов компьютеризация предприятия должна сопровождаться радикальным пересмотром существующей схемы управления. [13,19,21,32]

Сегодня наблюдаются массовые закупки ПК без какой-либо структуризации и системной организации их работы; приобретаются зарубежные пакеты на основе рекламных заявлений продавцов, обещающих решить сразу все проблемы заказчика и т.п. В результате "средства осваиваются", а для чего и какие из этого перспективы - должного внимания этим вопросам зачастую не уделяется. Поэтому главной задачей руководства на первом этапе внедрения проекта автоматизации системы управления - выработка стратегической линии проведения реконструкции самой системы управления на предприятии [10].

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

Бизнес-инжиниринг - это технологии управления, основанные на информационных моделях предприятия: организационно-функциональной структуры, бизнес-процессов, жизненного цикла продукта, а также моделях внешней среды [25].

Бизнес-инжиниринг, как и многие другие методы управления, пришел к нам с Запада. Там в 80-е годы появился и получил распространение метод революционного преобразования деятельности предприятия, коренной перестройки его бизнеса, который получил название "реинжиниринг". Его идеологи - М. Хаммер и Дж. Чампи выразили сущность реинжиниринга следующими словами: "Это фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов компании для достижения коренных улучшений в основных актуальных показателях их деятельности - стоимость, услуги, качество, темпы" [45]. Бизнес-процессы, одно из ключевых понятий, лежащее в основе реинжиниринга. Именно их совершенствование является огромным резервом повышения эффективности деятельности предприятия. А для этого необходимо осмыслить природу бизнес-процессов, понять, какое значение они имеют для предприятия, как следует их правильно изменять.

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

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

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

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

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

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

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

Функциональная организация предприятия характеризуется статичными элементами, такими как функции, организационная структура, регламенты. Процессная же динамична. Каждый процесс имеет свою цель. Критерием эффективности процесса является то, насколько оптимальный путь выбран для ее достижения. Цели всех процессов являются целями нижнего уровня. Через их реализацию достигаются цели верхнего уровня - цели компании. Управляя процессами и постоянно их совершенствуя, предприятие добивается высокой эффективности своей деятельности [25].

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

Оптимизация бизнес-процессов может осуществляться по двум основным направлениям: революционному и эволюционному.

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

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

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

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

Совершенствование технологии работы предприятий понимается в широком смысле как совершенствование всего механизма планирования и реализации производимой продукции и подразумевает всесторонний анализ функций управления на предмет:

·   необходимости и достаточности функций управления;

·   исключения их дублирования;

·   определения узких мест

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

·   полноты представления и рационального распределения по уровням функций планирования, маркетинга, контроля и др.;

·   определения затрат на выполнение конкретных функций;

·   анализа функций с точки зрения их трудоемкости и сложности.

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

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

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

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

Отдельный вопрос - введение специфических подразделений и определение их роли в деятельности предприятия.

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

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

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

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

1.2 Основные категории БП, качественные и количественные параметры БП, оптимизация ключевых параметров

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

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

Существуют следующие категории бизнес-процессов [43]:

·   Процессы, непосредственно обеспечивающие выпуск продукции;

·   Процессы планирования и управления;

·   Ресурсные процессы;

·   Процессы преобразования.

Бизнес-процесс характеризуется:

·   Технологией реализации бизнес-процесса;

·   структурой бизнес-системы;

·   средствами автоматизации, оборудованием, механизмами и т. п., обеспечивающими реализацию процесса [25].

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

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

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

Снабжение - включает приобретение материалов и услуг.

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

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

Доставка - включает процессы по перевозке и доставке продуктов к заказчику.

Управление - включает процессы стратегического планирования, бизнес-планирования и финансового контроля.

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

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

Качественными параметрами процесса принято считать результативность, эффективность и адаптируемость [30].

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

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

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

К количественным параметрам бизнес-процесса относятся производительность, длительность (или продолжительность), стоимость, количество входов и выходов [25].

Производительность - это отношение количества единиц на выходе к количеству единиц на входе.

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

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

Идея оптимизации ключевых параметров бизнес-процессов получила развитие в научном направлении “сокращение времени циклов” (Total Cycle Time Reduction) [27], которое по сути представляет реинжиниринг бизнес-процессов, сфокусированный в первую очередь на сокращении длительности бизнес-процессов.

Основными принципами сокращения длительности бизнес-процессов являются:

1. управление организацией как системой

2. упрощение процессов и продуктов

3. исключение шагов, не добавляющих ценности.

Последний принцип известен также как метод анализа цепочки ценностей [25].

Рассмотрим основные способы улучшения бизнес-процессов.

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

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

Непрерывное улучшение процессов предполагает долгосрочное и постепенное повышение эффективности бизнес-процессов. Подобный подход к совершенствованию бизнес-процессов широко распространен в Японии и других странах Тихоокеанского региона.

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

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

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

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

2. ИТ как средство управления проектами. Информационные технологии содействуют управлению проектами совершенствования бизнес-процессов, помогают анализировать существующие и определять новые процессы. Существующие в этой области программные средства можно условно разделить на две категории. Первая категория - программные средства, позволяющие управлять любыми проектами. К таким продуктам относятся, например, Microsoft Project. Базирующейся на принципах сетевого планирования и управления продукт позволяет детально планировать и управлять по ходу выполнения проекта всеми имеющимися в наличии задачами и ресурсами, не нарушая намеченные сроки и запланированный бюджет. Ко второй категории относятся специфические для проектов реинжиниринга бизнес-процессов средства, позволяющие моделировать существующие бизнес-процессы предприятия, а затем рассматривать различные варианты возможных бизнес-процессов и выбирать оптимальный вариант [25].

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

4. ИТ как средство построения корпоративных информационных систем (КИС). Информационные технологии помогают связать на основе единой корпоративной информационной системы различные направления бизнеса. Множество компаний - производители программного обеспечения, такие, как “SAP”, “IBM”, “BAAN”, предлагают интегрированные программные решения в области КИС. Например, информационная система R/3 компании “SAP” содержит несколько десятков модулей, охватывающих практически все виды деятельности крупной корпорации. Такое комплексное применение новейших информационных технологий позволяет резко увеличить эффективность функционирования предприятия в целом [46].

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

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

1.3 Основные этапы реорганизации бизнес-процессов. Подходы к автоматизации управления

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

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

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

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

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

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

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

·              упорядочивание информационных потоков (в том числе документооборота) внутри предприятия;

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

·              анализ требований и проектирование спецификаций корпоративных информационных систем;

·              рекомендации и предложения по применимости и внедрению существующих систем управления предприятиями (прежде всего классов MRP и ERP).

Структура подхода к разработке проектов приведена на рис.1.3.1 [21].

. Анализ первичных требований и планирование работ

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

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

Рис. 1.3.1 Структура подхода к разработке проектов

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

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

. Проведение обследования деятельности предприятия

В рамках данного этапа осуществляется:

·    предварительное выявление требований, предъявляемых к будущей системе;

·              определение оргштатной и топологической структур предприятия;

·              определение перечня целевых задач (функций) предприятия;

·              анализ распределения функций по подразделениям и сотрудникам;

·              определение перечня применяемых на предприятии средств автоматизации.

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

В качестве исходной информации при проведении обследования и выполнении дальнейших этапов служат:

·    данные по организационной структуре предприятия;

·              информация о принятых технологиях деятельности;

·              стратегические цели и перспективы развития;

·              результаты интервьюирования сотрудников (от руководителей до исполнителей нижнего звена);

·              предложения сотрудников по усовершенствованию бизнес-процессов предприятия;

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

·              опыт системных аналитиков в части наличия типовых решений.

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

. Построение моделей деятельности предприятия

На данном этапе осуществляется обработка результатов обследования и построение моделей деятельности предприятия следующих двух видов:

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

·              модели “как должно быть”, интегрирующей перспективные предложения руководства и сотрудников предприятия, экспертов и системных аналитиков и позволяющей сформировать видение новых рациональных технологий работы предприятия [21].

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

Переход от модели “как есть” к модели ”как должно быть” осуществляется следующими двумя способами.

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

2.       Радикальное изменение технологий и переосмысление бизнес-процессов (“жесткий” реинжиниринг) [21].

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

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

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

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

. Разработка системного проекта

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

На этом этапе определяются:

·    архитектура системы, ее функции, внешние условия ее функционирования, распределение функций между аппаратной и программной частями;

·              интерфейсы и распределение функций между человеком и системой;

·              требования к программным и информационным компонентам системы, необходимые аппаратные ресурсы, требования к базе данных, физические характеристики компонент системы, их интерфейсы;

·              состав людей и работ, имеющих отношение к системе;

·              ограничения в процессе разработки (директивные сроки завершения отдельных этапов, имеющиеся ресурсы, организационные процедуры и мероприятия, обеспечивающие защиту информации) [21].

Системный проект строится на основе модели “как должно быть” и включает функциональную модель будущей системы в соответствии с одним из общеупотребительных стандартов (например, IDEF0 или IDEF3), информационную модель, а также техническое задание на создание автоматизированной системы (например, в соответствии с ГОСТ 34.602-89) [26].

Системный проект, позволяет:

·    описать, "увидеть" и скорректировать будущую систему до того, как она будет реализована физически;

·              уменьшить затраты на разработку и внедрение системы;

·              оценить разработку по времени и результатам;

·              достичь взаимопонимания между всеми участниками работы (заказчиками, пользователями, разработчиками, программистами и т.д.);

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

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

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

На основании системного проекта осуществляется:

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

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

·              совместное с заказчиком принятие решения о выборе конкретной системы управления предприятием или разработке собственной системы;

·              разработка требований к техническим средствам;

·              разработка требований к программным средствам;

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

6. Разработка технического проекта

На данном этапе на основе системного проекта и принятых решений по автоматизации осуществляется проектирование системы. Фактически здесь дается ответ на вопрос: "Как (каким образом) мы будем строить систему, чтобы она удовлетворяла предъявленным к ней требованиям?".

При этом происходит расширение системного проекта:

·    за счет его уточнения;

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

Этап выполняется квалифицированными специалистами.

. Последующие этапы

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

·    наполнение системы фактическими данными;

·              построение процедур их обработки;

·              интеграция процедур внутри автоматизированных рабочих мест;

·              интеграция автоматизированных рабочих мест в систему [21].

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

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

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

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

·   инвестиционные ресурсы предприятия недостаточны для решения задачи автоматизации в полном объеме;

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

·   технология производства или иные условия не позволяют обходиться без использования автоматизированных систем [5].

Наиболее часто такой подход применяется для автоматизации производственных участков. Основное средство автоматизации - специализированные АСУ ТП. Применение принципа автоматизации предприятия по участкам для ряда предприятий единственно возможный способ повысить экономические показатели в условиях ограниченных инвестиционных ресурсов. Чтобы автоматизация по участкам была эффективна, необходимы стратегический и оперативный планы автоматизации. При этом стратегический план автоматизации, если выбрана стратегия автоматизации по участкам, должен периодически, не реже раз в год, пересматриваться. При ревизиях стратегического плана целесообразно особенное внимание уделить вопросам преемственности комплекса стандартов на информационные технологии, поддерживаемые на предприятии.

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

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

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

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

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

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

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

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

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

·   повышенная экономическая эффективность этого подхода по сравнению с другими (по участкам и направлениям);

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

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

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

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

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

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

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

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

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

2.1     Виды моделей бизнес-процессов, организация моделирования бизнеса.

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

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

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

2. в какой последовательности выполняются эти процедуры;

3. какие механизмы контроля и управления существуют в рамках рассматриваемого бизнес-процесса;

4. кто выполняет процедуры процесса;

5. какие входящие документы/информацию использует каждая процедура процесса;

6. какие исходящие документы/информацию генерирует процедуру процесса;

7. какие ресурсы необходимы для выполнения каждой процедуры процесса;

8. какая документация/условия регламентирует выполнение процедуры;

9. какие параметры характеризуют выполнение процедур и процессов в целом. [38]

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

1. математические (дисперсия, среднеквадратичное отклонение и т.п.);

2.       экономические (стоимость, убытки, прибыль);

.        технологические (время).

В зависимости от поставленной цели (описание, анализ или синтез), любой бизнес-процесс может быть представлен:

концептуальной моделью;

предметной моделью;

·   совокупностью знаковых моделей.

Концептуальная модель (КМ) представляет идеальный образ [4]. Детализация концептуальной модели, позволяющая экспериментировать с ней для получения необходимой информации, осуществляется в предметной и знаковой формах.

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

Функциональная модель отражает функционирование системы. Структурная модель отражает строение системы, взаимосвязи между ее элементами. [4]

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

Логико-лингвистическая (словесно-описательная) модель [33] описывает свойства на естественном языке. Графические модели можно разделить на портретные и условные. Портретная (иконическая) модель отображает свойства графическими средствами (чертеж, схема, фотография).

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

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

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

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

Применение имитационных моделей позволяет получить нужную информацию с помощью численных методов и расчетов на ЭВМ.

Если модель не позволяет проводить анализ, синтез объекта и получать прогноз по нему, то ее следует дополнять другими моделями.

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

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

.   показатели качества продукции и удовлетворенности потребителя;

2.       показатели длительности (время выполнения процесса, цикл, производительность и т.д.);

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

В соответствии с требованиями ISO 9001:2000 разделов 5.2 “Ориентация на заказчика” и 8.2.1 “Удовлетворенность потребителя” для потребителя основной группой показателей является 1-я, но для предприятия важны все группы. Для успешной реорганизации бизнес-процессов необходимо учитывать все группы показателей. При этом сложность задачи по оптимальному выбору системы, способа сбора и обработки данных по показателям окупается улучшением системы управления процессами, снижением затрат ресурсов и времени.

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

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

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

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

модель управления производством;

модель управления логистикой (снабжением и сбытом).

В эти категории можно отнести и ряд других моделей. Для их построения применимы популярные на Западе концепции управления - MRP (Manufacturing Resource Planning), DRP (Distribution Resource Planning), ERP (Enterprise Resource Planning), CSRP (Customer Synchronized Resource Planning) [18].

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

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

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

Бизнес-модель - это осязаемый результат, с помощью которого можно максимально конкретизировать цели внедрения ИСУ предприятия и определиться со следующими параметрами проекта:

1. перечень участков внедрения и последовательность их автоматизации;

2.       фактическая потребность в объемах закупаемого программного и аппаратного обеспечения;

.        реальные оценки сроков развертывания и запуска ИСУ;

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

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

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

В основе бизнес-модели всегда лежат бизнес-цели предприятия, по большому счету полностью определяющие состав всех базовых компонентов бизнес-модели [2]:

·    бизнес-функции, описывающие, ЧТО делает бизнес;

·              бизнес-процессы, описывающие, КАК предприятие выполняет свои бизнес-функции;

·              организационная структура, определяющая, ГДЕ исполняются бизнес-функции и бизнес-процессы;

·              фазы, определяющие, КОГДА (в какой последовательности) должны быть внедрены те или иные бизнес-функции;

·              роли, определяющие, КТО исполняет бизнес-процессы;

·              правила, определяющие связь между ЧТО, КАК, ГДЕ, КОГДА и КТО.

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

·    воздействия, инициирующие каждый шаг бизнес-процесса;

·              исполнители каждого шага (это могут быть как люди, так и программы и механизмы);

·              воздействия, регламентирующие данный шаг (законодательные акты, рыночные условия и т. п.);

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

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

В группе моделирования (внедрения) обязательно должна быть предусмотрена должность администратора бизнес-моделирования (АБМ). АБМ - это координатор усилий всей проектной группы по разработке модели. Ошибочно считать, что эту функцию должен выполнять «по совместительству» менеджер проекта. Его основная (и единственная) обязанность - управление проектом. АБМ же ведет оперативный аудит принимаемых в ходе внедрения решений, контролирует целостность базовой бизнес-модели и процесс ее корректировки, отслеживает оптимальность кодирования справочников и руководит процессом разработки интерфейсов внедряемой ИСУ с другими системами. Естественно, что АБМ подготавливает для менеджера проекта необходимую при принятии решений информацию. На ранних стадиях проекта функцию АБМ может и должен исполнять внешний консультант. Но с самого начала необходимо приставить к этому человеку специалиста-дублера, чтобы перенять опыт и полностью принять дела к началу опытной эксплуатации [6].

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

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

. Внутреннее тестирование разработчика

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

. Тестирование проектной группой

Желательно совместить эту стадию с первой, устранив тем самым лишнее ресурсоемкое звено в цепочке приемки модели. Данная стадия выделяется только тогда, когда условия реализации проекта внедрения ИСУ на предприятии выражаются в словосочетании «под ключ».

. Тестирование ключевыми пользователями

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

4. Опытная эксплуатация

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

2.2     Классификация инструментальных средств моделирования

Инструментальные средства, предназначенные для моделирования информационных систем, могут быть отнесены к одной из следующих категорий [47]:

·    локальные, поддерживающие один-два типа моделей и методов (Design/IDEF, ProCap, S-Designor, "CASE. Аналитик");

·              малые интегрированные средства моделирования, поддерживающие несколько типов моделей и методов (ERwin, BPwin);

·              средние интегрированные средства моделирования, поддерживающие от 4 до 10-15 типов моделей и методов (Rational Rose, Paradigm Plus, Designer/2000);

·              крупные интегрированные средства моделирования, поддерживающие более 15 типов моделей и методов (ARIS Toolset).

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

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

Типичный представитель малых интегрированных средств моделирования - комплект программных продуктов Platinum Technology (CA/ Platinum/Logic Works), основанный на популярных пакетах BPwin и Erwin.

BPwin поддерживает три методологии моделирования: IDEF0 (диаграммы функций), IDEF3 (только диаграммы процессов), DFD (диаграммы потоков данных) и обеспечивает интеграцию моделей трех типов без экспорта или импорта данных. Интеграция выполняется как путем слияния нескольких моделей, так и посредством переключения на различные методологии в процессе разработки отдельных диаграмм модели. Предусмотрено расширение возможностей анализа систем как в самом пакете BPwin (функционально-стоимостный анализ), так и с помощью экспорта данных в другие пакеты.поддерживает несколько разновидностей методологии информационного моделирования, основанной на ER-диаграммах (сущность - связь). Интеграция моделей BPwin с моделями ERwin выполняется путем обмена данными через функции экспорта/импорта.

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

К средним интегрированным средствам можно отнести такие известные продукты, как Rational Rose (Rational Software), Paradigm Plus (CA/Platinum), Designer/2000 (Oracle).Rose и Paradigm Plus основаны на объектно-ориентированном подходе к моделированию и ориентированы на метод UML (Unified Modeling Language).  Помимо UML поддерживаются и другие методы. Отличия между Rational Rose и Paradigm Plus состоят в основном в доступных пользователю типах диаграмм и методов [47].

Средства моделирования среднего класса предназначены для выполнения комплексного анализа систем. Они могут быть успешно применены при создании малых и средних ИСУП, особенно с этапа анализа спецификаций. Слабая сторона - недостаточные возможности для моделирования и анализа на верхнем уровне (анализ требований).  Крупные интегрированные средства моделирования. К этой категории относится инструментальное средство, специально предназначенное для проектирования крупных ИСУП, таких, например, как системы управления предприятием класса ERP. Это - семейство ARIS (ARIS Toolset, ARIS Easy Design) компании IDS Sheer AG. В ARIS воплощен практический опыт множества аналитиков, работающих в области проектирования ИСУП, а также учтены недостатки существующих инструментальных средств. Отличительная особенность ARIS - особое внимание к первому уровню анализа (анализ требований).

Не отказываясь от классификации инструментальных средств на локальные, малые, средние и крупные, используем также другую классификацию инструментальных средств, аналогичную классификации ИСУП на ERP - не-ERP.

Принадлежность к категории ERP для средств моделирования означает, что оно предназначено для выполнения комплексного анализа на всех стадиях (требования, спецификации, внедрение) разработки ИСУП класса ERP. Естественно, такое средство может быть использовано при создании любых других ИСУП, а не только ERP.

Если же средство моделирования принадлежит к категории не-ERP, это означает, что оно не предназначено для выполнения всех уровней анализа при проектировании ИСУП класса ERP, но его (средство) можно использовать при создании локальных, малых или средних ИСУП, не относящихся к классу ERP.

Из рассмотренных выше инструментальных средств к категории ERP можно отнести только ARIS.

Все рассмотренные выше инструментальные средства широко используются для моделирования и анализа систем, в том числе и при создании ИСУП.

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

Среди малых инструментальных средств доминируют пакеты BPwin и ERwin компании Platinum.

Локальные и малые инструментальные средства могут быть использованы при разработке соответственно локальных и малых ИСУП. Для средних и крупных ИСУП использование этих средств имеет смысл в качестве дополнения к более универсальному инструментальному средству средней категории [47].

Средства моделирования средней категории, как правило, основаны на использовании объектно-ориентированного подхода к моделированию и анализу систем. Фактическим стандартом для этой категории инструментальных средств является унифицированный язык моделирования UML. По данным исследовательской компании International Data Corporation, среди инструментальных средств, которые можно отнести к этой категории, лидирующее положение занимает пакет Rational Rose.

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

Система ARIS как крупное интегрированное средство моделирования имеет уникальные возможности для моделирования и анализа систем. Моделирование в ARIS может выполняться как "сверху вниз", так и "снизу вверх" [48].

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

.3 Основные методологии обследования организаций. Стандарт IDEF0, ARIS сравнительный анализ

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

Семейство методологий IDEF, является государственным стандартом в США. Данное семейство состоит из методологии функционального моделирования IDEF0 и методологии информационного моделирования IDEF1X. IDEF - методологии создавались в рамках предложенной ВВС США программы компьютеризации промышленности - ICAM, в ходе реализации которой выявилась потребность в разработке методов анализа процессов взаимодействия в производственных (промышленных) системах. Принципиальным требованием при разработке рассматриваемого семейства методологий была возможность эффективного обмена информацией между ВСЕМИ специалистами - участниками программы ICAM (отсюда название: Icam DEFinition - IDEF). После опубликования стандарта он был успешно применен в самых различных областях бизнеса, показав себя эффективным средством анализа, конструирования и отображения бизнес-процессов (он активно применяется и в отечественных государственных структурах, например в Государственной Налоговой Инспекции). Более того, собственно с широким применением IDEF (и предшествующей методологии - SADT) и связано возникновение основных идей реинжиниринга бизнес-процессов [49].

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

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

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

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

3   IDEF1X (IDEF1 Extended) - методология построения реляционных структур. IDEF1X относится к типу методологий “Сущность-взаимосвязь” (ER - Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

4   IDEF2 - методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. Однако в настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе “раскрашенных сетей Петри” (CPN - Color Petri Nets);

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

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

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

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

Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique). Исторически, IDEF0, как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing) и была предложена департаментом Военно-воздушных Сил США. Собственно семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=ICAM DEFinition) [47].1981 года стандарт IDEF0 претерпел несколько незначительных изменения, в основном ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST) [48].

Основные элементы и понятия IDEF0

В основе методологии лежат четыре основных понятия:

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

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

8   Верхняя сторона имеет значение “Управление” (Control);

9   Левая сторона имеет значение “Вход” (Input);

Таблица 2.3.1

Основные элементы IDEF0

Таблица 2.3.2

Основные элементы IDEF3

1   Правая сторона имеет значение “Выход” (Output);

2   Нижняя сторона имеет значение “Механизм” (Mechanism) [39].

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

Таблица 2.3.3

Типы стрелок используемых в IDEF

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер [9].

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

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label).

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

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

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

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

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

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

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

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

В процессе декомпозиции, функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком - Child Box). В свою очередь, функциональный блок - предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит - родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. Важно отметить, что в каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 - модели. Наглядно принцип декомпозиции представлен на рисунке 2.3.1. Каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует.

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

Нотация ARIS eEPC расшифровывается следующим образом - Extended Event Driven Process Chain - расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером. В таблице 2.3.4 и таблице 2.3.5 приводятся основные используемые в рамках нотации ARIS eEPC объекты [39].

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

Рисунок 2.3.1 Декомпозиция функциональных блоков

Таблица 2.3.4

Основные элементы ARIS

Таблица 2.3.5

Основные элементы ARIS

Нотация eEPC построена на определенных семантических правилах описания:

1. каждая функция должна быть инициирована событием и должна завершаться событием;

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

Сравнительный анализ нотаций ARIS и IDEF приводится в следующей таблице 2.3.6 [39].

Одним из важнейших аспектов описания моделей бизнес-процессов является отражение на модели управляющих воздействий, обратных связей по контролю и управлению процедурой. В нотации ARIS eEPC управление процедурой может быть отражено только при помощи указания входящих документов, которые регламентируют выполнение процедуры, и последовательности выполнения процедур во времени (запускающие события). В отличие от ARIS, в нотации IDEF0 каждая процедура должна иметь хотя бы одно управляющее воздействие (вход управления - стрелка сверху). Если при создании модели в eEPC указывать только последовательность выполнения процедур, не заботясь об отражении управляющих документов и информации, полученные модели будут иметь низкую ценность с точки зрения анализа и дальнейшего использования. К сожалению, именно эта ошибка наиболее распространена на практике. Создается модель Work Flow (поток работы), отражающая простую последовательность выполнения процедур и входящих/исходящих документов, при этом управляющие (контрольные) воздействия на функции в модели не отражаются. Реальные процессы управления могут остаться «за кадром» на 30-90% [39].

Если пытаться отразить все условия и ограничения, определяющие выполнение функций, то потребуется описать большое количество событий и входящей информации (например, устных распоряжений руководителей), и модель станет сложной и плохо читаемой. (Эти недостатки присущи так же и нотации IDEF3). Указанных недостатков нет у нотации IDEF0. В то же время, на моделях в IDEF0 не предусмотрено использование символов логики выполнения процесса [9].

Таблица 2.3.6

Сравнительный анализ нотаций

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

Функциональные возможности инструментальных средств моделирования ARIS Toolset и BPwin можно корректно сравнивать только по отношению к определенному кругу задач. В данном исследовании рассматривается задача формирования моделей (описания) бизнес-процессов предприятия. Каждая из рассматриваемых систем имеет свои преимуществ и недостатки. В зависимости от решаемых задач эти преимущества могут как усиливаться, так и наоборот. То же касается и недостатков: недостаток системы в рамках одного проекта, может не быть недостатком в рамках другого. Например, отсутствие четких соглашений по моделированию управляющих воздействий в рамках eEPC ARIS может привести к созданию моделей, не отвечающих на поставленные вопросы [47], в то время как нотация IDEF0 системы BPwin позволяет решить эту задачу [43]. С другой стороны, описание процедуры, выполняемой одним сотрудником, может быть описано более адекватно при помощи eEPC ARIS, чем IDEF0 или IDEF3 BPwin. Сравнение функциональных возможностей систем приводится в следующей таблице.

Сравнивая две системы, следует сразу отметить, что для хранения моделей в ARIS используется объектная СУБД, и под каждый проект создается новая база данных. Для удобства пользователя модели (объекты моделей) могут храниться в различных группах, организованных в зависимости от специфики проекта. Вполне естественно, что в ARIS-е предусмотрены различные функции по администрированию базы данных: управление доступом, консолидация и т.п [42]. В BPwin данные модели хранятся в файле, что существенно упрощает работу по созданию модели, но с другой стороны ограничивает возможности по анализу объектов модели. В ModelMart так же предусмотрено администрирование базы данных [26].

Часто одним из недостатков BPwin сторонники ARIS-а называют ограничение по количеству объектов на диаграмме. Однако опыт реальных проектов показывает, что для проекта, результаты которого можно реально использовать (критерий - обозримость), количество объектов в базе данных ARIS или модели BPwin составляет 150-300. Это означает, что при 8 объектах на одной диаграмме, общее количество диаграмм (листов) в модели составит 20-40. Базы данных ARIS Toolset (как и BPwin), содержащие более 500 объектов, фактически невозможно использовать.

Таблица 2.3.7

Сравнительный анализ программных средств

Следует подчеркнуть, что модель создается для выделения и анализа проблем, т.е. требуется детальное описание наиболее сложных, проблемных областей деятельности, а не тотальное описание всех процессов. Как ни странно, среди директоров компаний существует вера в то, что детальное описание процессов само по себе представляет ценность и может решить многие проблемы. Это далеко не так. Именно понимание того, что нужно описывать и какие аспекты функционирования реальной системы при этом отражать, определяет успех проекта по моделированию бизнес-процессов.предоставляет существенно больше возможностей по работе с отдельными объектами модели, но именно вследствие чрезмерного количества настроек работа по созданию модели должна регламентироваться сложной, многоаспектной документацией - т.н. «Соглашениями по моделированию». Разработка этих «Соглашений» само по себя является сложной, дорогой и требующей значительного времени (1-3 месяца) и квалифицированных специалистов задачей. Если проект с использованием ARIS начинается без детальной проработки таких соглашений, то вероятность создания моделей бизнес-процессов, не отвечающих на поставленные вопросы, составляет 80-90% [26]. В свою очередь, BPwin отличается простотой в использовании, и достаточной строгой регламентацией при создании диаграмм (стандарт IDEF и рекомендации по его применению, бланк IDEF для создания диаграммы, ограниченное количество обязательно заполняемых полей, ограничение количества объектов на одной диаграмме и т.д.). ARIS, безусловно, является более «тяжелым» инструментом, по сравнению с BPwin, но это в итоге оборачивается значительными трудностями и высокими затратами на его эксплуатацию.

Анализируя вышесказанное можно предложить следующие рекомендации по применению систем в зависимости от типовых задач.

Различные ситуации применения инструментальных средств моделирования бизнес-процессов и их экспертная оценка по 5-бальной шкале показаны в следующей таблице 2.3.8 [9].

Рисунок 2.3.3 Позиционирование программных средств

Таблица 2.3.8

Экспертная оценка инструментальных средств

Таким образом, для ведения небольших по масштабам (малые и средние предприятия, 2-5 человека в группе консультантов) и длительности (2-3 месяца) проектов рационально использовать BPwin. Для крупных и/или длительных проектов (например, внедрение системы непрерывного улучшения бизнес-процессов, ISO, TQM) больше подходит ARIS. В этом случае подготовительные работы по созданию регламентирующей документации могут занять 1-3 месяца, но это является необходимым элементом последующей успешной работы.

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

По итогам второй главы можно сделать следующие выводы.

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

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

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

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

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

Для моделирования с целью оптимизации отдельного бизнес-процесса наиболее подходящей является программная среда BPwin.

3. МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССА “ОБСЛУЖИВАНИЕ КЛИЕНТА” НА УУПП “АВТОКОНТАКТ” ВОС

.1 Описание проблемы, цели и задачи моделирования

УПП «Автоконтакт» ВОС - государственное, промышленное предприятие Всероссийского Общества Слепых. Основной сферой деятельности является производство комплектующих на автомобили УАЗ и товаров народного потребления. За последние три года был получен ряд заказов от Волжского Автомобильного Завода.

Само предприятие функционирует более 50 лет. На УПП «Автоконтакт» ВОС сложились давние традиции, как в управлении, так и на производстве. Средний стаж рабочих составляет около 30 лет.

«Автоконтакт» является учебно-производственным предприятием Всероссийского Общества Слепых. Основная задача руководства - это обеспечение работой инвалидов по зрению. УПП «Автоконтакт» ВОС имеет льготное налогообложение. Распределение прибыли осуществляется через центральный ВОС. Обязательным условием существования этой организации является то, что численность инвалидов по зрению на предприятии должна быть не менее 52% от численности всего персонала.

На основании пункта 1.3 был разработан список мероприятий для организации моделирования деятельности УУПП “Автоконтакт” ВОС.

Список мероприятий:

1. Выявить потребности в моделировании;

2. Сформировать цель процесса моделирования;

3. Организовать рабочую группу;

4. Распределить полномочия;

5. Организовать обучение персонала;

6. Установить сроки моделирования;

7. Определить затраты на этап моделирования и автоматизации в целом;

8. Определить степень детализации модели;

9. Выбрать средство моделирования.

В соответствии со списком мероприятий рассмотрим организацию процесса моделирования.

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

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

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

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

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

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

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

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

АБМ подготавливает для менеджера проекта необходимую при принятии решения информацию. Функции менеджера проекта должен выполнять сотрудник УУПП «Автоконтакт» ВОС. Ответственность за разработку и поддержку бизнес-модели возложить на плановый отдел.

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

. Минимальное время на этап обучения составляет 2 недели (цикл семинаров).

. Стоимость проекта, как уже говорилось в пункте 1.3, точно оценить сложно. Но можно рассчитать сумму основных статей затрат (таблица 3.1).

Таблица 3.1

Затраты на организацию процесса моделирования

1. СПМ складывается из стоимости программного средства, стоимости процесса обучения моделированию и стоимости консалтинговых услуг. Лицензированная версия BPwin стоит порядка 600 у. е. [26]. Процесс обучения 100 у. е. за 2 недели семинаров на человека (группа 5 человек). Консультационные услуги - 1000 у. е. [21]

СПМ=600 у.е. + (100 у.е. * 5 ) + 1000 у.е.= 2 100 у.е.

. СПП порядка 1500 у.е. [5].

. Для автоматизации документооборота необходимо дополнительно 7 АРМ, среди них: технологический одел, начальник производства, цех №1, цех №2, цех №3, отдел технического контроля, инженер по маркетингу, центральный склад. Если принимать среднюю стоимость одного АРМ равной 1000 у.е. то:

САРМ= 1 000 у.е.*7 шт.=7 000 у.е.

. СЛС порядка 1000 у.е.

. СКУ составляет 1500 у.е. в месяц [автоматизация управления], проект рассчитан на 6 месяцев.

СКУ=1500 у.е. * 6 =9 000 у.е.

. СОП на практике сравнимо со стоимостью обучения персонала при моделировании

СОП =100 у.е. * 7= 700 у.е. [5]

. Согласно статистике, достоверность модели к моменту ее завершения составляет не более 70% [43], так, что имеет смысл описать только “сквозные ” бизнес-процессы, каждый из которых раскрывает последовательность шагов предприятия на пути к извлечению прибыли от того или иного вида деятельности.

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

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

. Для анализа бизнес-процессов был выбран метод моделирования и анализа бизнес процессов на основе BPwin 2.5.

Выбор данного продукта обусловлен следующими причинами:

·   Наглядное представление результатов;

·   Возможность проведение функционально-стоимосного и временного анализа

·   Соответствие продукта масштабам проводимого анализа.

.2 Моделирование и анализ бизнес процесса “Обслуживание клиента”

Анализируя отчет по основным технико-экономическим показателям деятельности УПП «Автоконтакт» ВОС было выявлено, что предприятие крайне нестабильно и имеет ряд неудовлетворительных параметров среди которых: дебиторская задолженность 12 000 тыс. рублей в год.

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

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

Рис. 3.1 Контекстная диаграмма “Обслуживание клиента”

На основе BPwin 2.5 была построена концептуальная модель деятельности предприятия представленная на рисунке 3.3. декомпозиция модели отражены на рисунках 3.4-3.6.

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

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

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

Далее согласно диаграмме анализируем процесс ’’Анализ и согласование заявки клиента’’. Для этого необходимо исследовать логику процесса представленную на рис 3.4. Диаграмма выполнена в соответствии со стандартом IDEF3 (поток работ).

Анализ диаграммы выявил:

1. Дублирование полномочий на этапах ’’Согласовать заявку с цехом №1’’ и “Согласовать с плановым отделом”.

2. Незавершенность цикла “уведомить клиента о невозможности выполнения заказа”

После проведения анализа диаграммы была разработана следующая схема процесса “Анализ и согласование заявки клиента” которая представлена на рис. 3.11.

Очевидно, что бы предотвратить возникновение дебиторской задолженности необходимо проводить анализ платежеспособности заказчика. Исследуем процесс “Отгрузка покупателю”. Модель процесса представлена на рис. 3.6 (IDEF3).

Из диаграммы видно, что отсутствуют процессы:

·   “Получение от заказчика уведомления о выполнении условий по оплате”,

·   “Регистрация отступления от контрольных дат по договору”,

·   “Выставление претензий по нарушению условий договора”.

Рис. 3.7 “Отгрузка покупателю”

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

Для логической завершенности модели “Обслуживание клиента” необходимо детализировать процесс “Отгрузка покупателю” рис (3.7).

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

Чтобы исключить в дальнейшем подобных проблем необходимо:

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

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

·   Исключить практику отгрузки продукции без договора и гарантий по оплате.

·   Самостоятельно начать осваивать рынок, отказываясь от посредников.

На рисунках 3.2.8-3.2.13 представлен бизнес-процесс “Обслуживание клиента” “как должно быть”.

Автоматизация по направлению “документооборот” позволит оптимизировать следующие параметры бизнес-процессов:

·   Время оформления документов снизится примерно в 5-6 раз за счет автоматического пересчета и формирование отчетности [25];

·   Стоимость бизнес-процесса за счет снижение потерь, при не правильном оформлении договора и высвобождении рабочих мест;

·   Качество информации (достоверность и своевременность).

Анализируя процесс “Обслуживания клиента ” был выявлен ряд недостатков, среди которых:

·   Дублирование полномочий;

·   Нарушение логики процесса заключения договора;

·   Выявлены процессы, за которые никто не несет ответственности.

Для устранения перечисленных недостатков была сформирована модель “как должно быть”.

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

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

ЗАКЛЮЧЕНИЕ

Данная дипломная работа посвящена проблемам совершенствования бизнес-процессов на основе разработки и анализа его модели.

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

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

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

В работе были определены виды моделей бизнес-процессов их особенности. Особое внимание было уделено построению графических моделей в соответствии со стандартом IDEF. В рамках дипломной работы был проведен сравнительный анализ наиболее популярных нотаций: IDEF и ARIS, даны рекомендации по их применению в зависимости от поставленных задач. На основе анализа нотаций было проведено исследование возможностей программных продуктов в основу которых положены данные методологии. Так же было проведено позиционирование систем BPwin и ARIS Toolset в зависимости от функциональных возможностей систем и простоты использования в проекте.

В работе был разработан список мероприятий для организации процесса моделирования деятельности УУПП “Автоконтакт” ВОС, в котором определены цели моделирования, состав рабочей группы, распределены полномочия и ответственность между ее членами. Так же были установлены сроки моделирования и выбран и обоснован метод и средство разработки модели.

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

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