Реинжениринг

Автор: Пользователь скрыл имя, 23 Ноября 2011 в 16:44, реферат

Описание работы

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

Работа содержит 1 файл

Реижиниренг.docx

— 72.32 Кб (Скачать)

«Продажи» — от выявления потенциального клиента  до получения заказа,

«Выполнение заказа» — от оформления заказа до осуществления платежа,

«Обслуживание»  — от получения запроса до разрешения ; возникшей проблемы.

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

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

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

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

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

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

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

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

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

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

Сотрудники. Объект с данными о сотрудниках  предприятия.

Должность. Объект, содержащий описание типовых  должностей предприятия.

Квалификационные  требования. Объект, содержащий описание квалификационных требований предприятия  к типовым и штатным должностям.

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

     17. 4 Примеры диаграмм взаимодействия

     Диаграммы взаимодействия (interaction diagrams) являются моделями, описывающими поведение взаимодействующих  групп объектов. Как правило, диаграмма  взаимодействия охватывает поведение  объектов в рамках только одного варианта использования. На такой диаграмме  отображается ряд объектов и те сообщения, которыми они обмениваются между  собой. Проиллюстрируем данный подход на примере достаточно простого варианта использования, который описывает  следующее поведение:

     • Окно Ввода Заказа посылает Заказу сообщение "приготовиться".

     • Заказ посылает данное сообщение каждой Строке заказа в данном Заказе.

     • Каждая Строка заказа проверяет состояние определенного Запаса товара:

     Если  данная проверка удовлетворяется (результат  — true), то Строка заказа удаляет соответствующее  количество товара из Запаса. В противном  случае количество Запаса снижается  до уровня повторного заказа, и Запас  запрашивает новую поставку товара.

     Существуют  два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams).

     На  диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии (рис. 2.1). Эта вертикальная линия  называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия. Такую форму представления  впервые ввел Ивар Якобсон.Каждое сообщение  представляется в виде стрелки между  линиями жизни двух объектов. Сообщения  появляются в том порядке, как  они показаны на странице — сверху вниз. Каждое сообщение помечается, как минимум, именем сообщения; при  желании можно добавить также  аргументы и некоторую управляющую  информацию и, кроме того, можно показать само делегирование (self-delegation) — сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает  на ту же самую линию жизни. Из всей возможной управляющей информации два ее вида имеют существенное значение. Во-первых, это условие, показывающее, когда посылается сообщение (например, [нужен Повторный Заказ = "true"]). Сообщение посылается только при выполнении данного условия. Другой полезный управляющий маркер — это маркер итерации, показывающий, что сообщение посылается много раз для множества объектов-адресатов (например,* приготовиться). Диаграммы последовательности очень просты и наглядны (в этом заключается самое большое их достоинство) и существенно помогают разобраться в процессе поведения системы. Диаграмма (см. рис. 2.1) содержит возврат, означающий не новое сообщение, а возврат из сообщения. На диаграмме возврат отличается от обычных сообщений тем, что его стрелка не сплошная, а имеет вид пары линий. Диаграммы последовательности можно также использовать для представления параллельных процессов. На рис. 2.2 изображен ряд объектов, участвующих в проверке банковской транзакции. В момент создания Транзакции она порождает Координатор Транзакции в целях координации проверок, выполненных Транзакцией.Транзакцией. Этот координатор создает несколько объектов Транзакционного Контролера (в данном случае два объекта), каждый из которых отвечает за определенную проверку. Такой процесс облегчает создание различных дополнительных процессов проверки, поскольку каждая проверка вызывается асинхронно и выполняется параллельно с другими. Когда Проверка Транзакции завершается, она посылает соответствующее сообщение Координатору Транзакции. Координатор проверяет, все ли проверки сообщили о своем выполнении. Если нет, то координатор не выполняет никаких действий. Если же все проверки завершились успешно, как в данном случае, то координатор сообщает Транзакции о нормальном завершении. В диаграмму последовательности на рис. 2.2 введен ряд новых элементов. Во-первых, это активизации, появляющиеся явно в том случае, когда метод становится активным либо во время его выполнения, либо при ожидании результата выполнения какой-либо процедуры. Во-вторых, половинные стрелки обозначают асинхронные сообщения. Асинхронное сообщение не блокирует работу вызывающего объекта. Таким образом, он может продолжать свой собственный процесс. Асинхронное сообщение может выполнять одну из трех функций:

     • создавать новую ветвь процесса (в этом случае оно связано с самой верхней частью активизации);

     • создавать новый объект;

     • устанавливать связь с уже выполняющейся ветвью процесса.

     Удаление  объекта показано с помощью большого знака "X". Объекты могут выполнить  самоуничтожение или могут быть уничтожены посредством еще одного сообщения. Используя механизм активизаций, можно более четко показать смысл  само делегирования. Без них, или  без такого обозначения с помощью  столбиков, которое здесь используется, довольно трудно определить, где же выполняются следующие после  само делегирования вызовы — то ли в вызывающем методе, то ли в вызываемом методе. Активизации вносят ясность в этот вопрос.Вторым видом диаграммы взаимодействия является кооперативная диаграмма, на которой экземпляры объектов показаны в виде пиктограмм. Как и на диаграмме последовательности, здесь стрелки обозначают сообщения, обмен которыми осуществляется в рамках данного варианта использования. Их временная последовательность, однако, указывается путем нумерации сообщений. Нумерация сообщений делает восприятие их последовательности более трудным, чем в случае расположения линий на странице сверху вниз. С другой стороны, такое пространственное расположение позволяет более легко отразить некоторые другие моменты, на пример можно показать взаимосвязь объектов, перекрывающиеся компоненты или другую информацию. Для кооперативных диаграмм можно использовать один из нескольких вариантов нумерации. В UML применяется десятичная схема нумерации (рис. 2.3), поскольку в этом случае понятно, какая операция, вызывает какую операцию, хотя может быть труднее разглядеть их общую последовательность.Независимо от используемой схемы нумерации на диаграмме можно разместить такого же рода управляющую информацию, как и на диаграмме последовательности. На рис. 2.3 можно увидеть различные формы схемы именования объектов, принятые в UML. Общая форма имеет вид <Имя Объекта: Имя Класса>, где-либо имя объекта, либо имя класса может отсутствовать. При отсутствии имени объекта остается двоеточие, чтобы было понятно, что это имя класса, а не объекта.

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

прецедент включает:

Описание  проблемы.

Решение этой проблемы.

Результат (обоснованность) применения решения.

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

перечень  того, что выполнено,

результат,

способ восстановления (в случае отказа),

перечень  того, что можно сделать, чтобы  избежать отказа,

результаты  восстановления.

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

Ö = O (Ï),

где Ï - вектор входных параметров объекта управления, Ö - вектор выходных параметров объекта  управления.  

Это отображение  может иметь сложную функциональную форму, но обязано удовлетворять  двум условиям:

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

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

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

Информация о работе Реинжениринг