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

Размещено на http://www.allbest.ru/

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

1. Задачи реинжиниринга информационно-управляющих систем

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

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

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

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

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

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

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

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

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

Сущность реинжиниринга наглядно демонстрируется следующим примером.

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

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

2. Анализ результатов и принятие решений. Понятие бизнес-процесса

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

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

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

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

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

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

Предлагается следующая структура бизнес-процесса:

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

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

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

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

реинжиниринг информационный управляющий

3. Реализация процесса реинжиниринга в виде системного проекта

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

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

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

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

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

Реинжиниринг ИУС, основанных на компьютерных технологиях, предполагает определенную культуру проектирования. Так по методологии SADT предполагается разработка функциональной (ФМ), информационной (ИМ) и динамической (ДМ) моделей, составляющих основу системного проекта информационно-управляющей системы (СП ИУС). Далее реализация СП ИУС может быть осуществлена по CASE технологии либо по технологии обычного с применением алгоритмических языков и программирования языков СУБД, либо по технологии экспертных систем.

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

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

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

По оценкам специалистов разработка системного проекта занимает приблизительно 70-80% времени, затрачиваемого на разработку ИУС, в то время как реализация его на выбранном программно-аппаратном комплексе - соответственно 20-30%. Модификация самого системного проекта, как правило, не требует больших финансовых и временных затрат.

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

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

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

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

4. Применение CASE-технологий

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

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

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

Преимущества CASE-технологии по сравнению с традиционной технологией оригинального проектирования сводятся к следующему:

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

-возможность повторного использования компонентов разработки.

-поддержание адаптивности и сопровождения ЭИС.

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

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

-возможность коллективной разработки ЭИС в режиме реального времени.

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

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

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

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

К средствам, распространяемым на Российском рынке относятся Bpwin, Silverrun, Oracle Designer, основанные на структурном подходе к проектированию, а также Ratoinal Rose, Re Think, основные на объектно-ориентированном подходе.

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

Основные понятия CASE-технологий и CASE-средств

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

Метод- это процедура или техника генерации описаний компонентов ЭИС (например, проектирование потоков и структур данных).

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

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

В практике использования CASE-средств для бизнес - проектирования выделяют два подхода: структурный и объектный.

Структурный подход

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

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

принцип иерархического упорядочения;

принцип абстрагирования;

принцип непротиворечивости;

принцип структурирования данных;

принцип формализации;

принцип управления;

принцип полноты;

принцип независимости данных;

Для структурного метода характерно:

разбиение на уровни абстракции с ограничением числа элементов на каждом уровне от 3 до 7;

ограниченный контекст, включающий лишь существенные на каждом уровне детали;

использование строк формальных правил записи;

последовательное приближение к конечному результату.

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

Структурный подход опирается на методологию SADT, которая в отличие от других, поддержана целым рядом САПРов, построенных на стандартах IDEF0, IDEF1, IDEF1X, IDEF/CPN и являющихся по сути подстандартами SADT, который является языком этих стандартов.

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

SADT-методология позволяет проанализировать все аспекты функционирования системы, а также последовательно приближает нас к использованию CASE-технологии, так как реализуется с помощью CASE-средства Design/IDEF, BP-Win, ER-Win.

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

Рассмотрим CASE-средства поддерживающие методологии SADT в области проектирования систем.

Средства Design/IDEF и BP-Win используется для создания функциональной модели (ФМ), которая является иерархически структурированным изображением функций производственной системы и ее связей со средой, семантики, отражающей эти функции.

Наиболее распространенными средствами, описывающими функциональную структуру системы и отношения между данными являются:

- DFD (Data Flow Diagrams) -диаграммы потоков данных;

- SADT (Structured Analisis and Design Technigue) - метод структурного анализа и проектирования, - модели и соответствующие функциональные диаграммы;

- ERD (Entity - Relationship Diagrans) - диаграммы «сущность - связь».

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

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

IDEF/CPN и BP-Win позволяет построить динамическую модель (ДМ), отражающую изменение во времени поведения функций, информационных ресурсов, производственной системы или среды.

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

Объектный подход

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

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

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

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

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

Преодоление недостатков структурного и объектного подходов видят в использовании унифицированной методологии UML (Unifiecd Modeling Language).

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

диаграмма классов;

диаграмма прецедентов;

диаграмма взаимодействий;

диаграмма состояний;

диаграмма компонентов;

диаграмма применения (развертывания)

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

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

Характерным CASE средством объектно-ориентированного анализа и проектирования, основанным на языке UML, является Rationale Rose фирмы Rational Software Corporation.

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

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

спецификация классов, объектов, атрибутов и операций;

заготовки текстов программ.

Размещено на Allbest.ru