Цель:освоить на практике особенности работы в среде деловой графики и демо-версии систем поддержки управления предприятием, научиться приемам построения моделей бизнес- процессов в различных нотациях.
Теоретические вопросы
— Реализация и внедрение проекта РБП.
— Состав и функции команд РБП.
— Инструментальные программные средства РБП.
— Перечислите этапы реинжиниринга бизнес-процессов.
— Какова роль мотивации к проведению реинжиниринга для различных групп сотрудников компании?
— Что должна содержать директива на проведение реинжиниринга?
— Перечислите основных участников проекта по реинжинирингу, их роли и обязанности.
— Как классифицируются, выделяются и ранжируются бизнес- процессы? Приведите примеры.
— Как осуществляется внедрение проекта реинжиниринга бизнес-процессов?
— Какова организационная структура проекта РБП?
— Отличается ли на ваш взгляд команда проекта по РПБ в России и за рубежом? Ответ обоснуйте.
Пример коммуникационного видеоролика по продвижению проекта реинжиниринга бизнес-процессов в банке
— Каково значение информационных технологий при проведении работ по РБП?
— Какие информационные сервисы используются для автоматизации прикладных и информационных процессов в качестве средств реинжиниринга?
Основные этапы реинжиниринга компании (организации)?
В целом работа по реинжинирингу бизнеса состоит из двух основных этапов: ―обратного‖ и ―прямого‖ инжиниринга компании. Для того, чтобы изменить систему управления, ее нужно сначала описать и оценить. Поэтому реинжиниринг начинается с описания и оценки ситуации ―»как есть». Для того чтобы понять, как и зачем менять, надо разработать цели и стратегию изменений, модель системы управления ―»как нужно». После этого реинжиниринг системы управления требует разработки плана действий по переходу из ситуации ―»как есть» в ситуацию ―»как надо». Поэтому в качестве необходимых шагов реинжиниринга компании можно выделить:
1. Выбор стратегических приоритетов компании для формулирования целей бизнес- реинжиниринга и определения наиболее важных бизнес-процессов компании.
2. Создание модели существующей компании ―»как есть» на основе моделирования бизнес- процессов и функциональной структуры компании до начала проведения изменений.
3. Анализ модели существующей компании и выявление узких мест в компании c точки зрения функциональной структуры компании и ее бизнес-процессов.
4. Разработка новой функциональной структуры и бизнес-процессов компании на основе методов бизнес-реинжиниринга
5. Разработка и организация использования поддерживающих информационных систем. При этом определяются требуемые ресурсы (оборудование, программное обеспечение) и при необходимости реализуется специализированная информационная система.
6. Переход компании на новую функциональную структуру и бизнес-процессы, то есть внедрение новой системы управления в практику.
Как правило, перечисленные шаги выполняются не последовательно, а частично параллельно, причем некоторые шаги повторяются несколько раз.
Преодоление сопротивлений изменениям при оптимизации бизнес-процессов и организационной структуры
Источник: helpiks.su
5.1.3. Организационные формы реинжиниринга бизнес-процессов
Реинжиниринг бизнес-процессов (РБП) в узком смысле предшествует проектированию ЭИС и соответствует в традиционном представлении этапу системного анализа, на котором, в частности, определяются требования к информационной системе. Вместе с тем задачи нестандартного выделения бизнес-процессов, обеспечивающих резкое повышение эффективности деятельности предприятия, обусловливают разработку новых организационных форм участия специалистов в работах по реинжинирингу.
Сам по себе реинжиниринг бизнес-процессов (БП) представляет творческую деятельность коллективов специалистов, вырабатывающих концепцию осуществления бизнес-процессов с использованием передовых информационных технологий. К таким коллективам предъявляются следующие требования:
· участие представителей высшего звена управления или лидеров проекта на всех этапах реинжиниринга бизнес-процессов, которые отвечают за выработку и реализацию решений по реинжинирингу бизнес-процессов;
· совместная работа пользователей (владельцев бизнес-процессов) и групп (команд) реинжиниринга по определению содержания перепроектируемых бизнес-процессов;
· включение сторонних консультантов в состав групп реинжиниринга на равных правах с работниками предприятия;
· междисциплинарный характер состава участников групп реинжиниринга, включающих представителей всех взаимодействующих в бизнес-процессе подразделений;
· отвлечение участников групп реинжиниринга от основной работы на период реинжиниринга бизнес-процессов;
· контроль со стороны групп реинжиниринга реализации и внедрения сформированного проекта;
· координация работы групп реинжиниринга по нескольким бизнес-процессам на уровне методологических центров;
· непрерывное планирование и контроль работ по реинжинирингу бизнес-процессов со стороны администрации предприятия.
В соответствии с перечисленными требованиями М. Хаммер и Д.Чампи определили организационную структуру проекта реинжиниринга бизнес-процессов (рис. 5.6).
Лидер проекта – это менеджер верхнего звена управления, который наделен полномочиями возглавлять работы по реинжинирингу бизнес-процессов на всех его этапах. Лидер проекта в полной мере осознает задачи реинжиниринга, их сложность и трудоемкость, и во многом благодаря его энергии обеспечивается успех проекта. Поэтому лидер проекта не может быть формально назначен без осознания им необходимости и возможности реинжиниринга, а также способности переключить основное рабочее время на проведение реорганизации предприятия.
Важнейшие требования, предъявляемые к лидеру проекта, заключаются, с одной стороны, в способности концептуально мыслить, обобщая модели всех реорганизуемых бизнес-процессов, а, с другой стороны, в способности мотивировать проведение работ по реинжинирингу бизнес-процессов со стороны всех его участников.
Основные методы работы лидера проекта заключаются в следующих мероприятиях:
· в проведении собраний с коллективом работников предприятия, на которых ставятся задачи реинжиниринга, объясняется роль сотрудников и их участие в реинжиниринге бизнес-процессов;
· в подборе и контроле работы кадров (владельцев процесса, групп реинжиниринга, методологических центров);
· в проведении координационных совещаний по ходу проведения реинжиниринга бизнес-процессов;
· в участии в заседаниях руководящего комитета на стадиях планирования, контроля и приемки работ по реинжинирингу бизнес-процессов.
Владельцы бизнес-процессов – это будущие администраторы процессов, которые на стадии реинжиниринга выполняют обеспечение проекта в рамках каждого отдельного бизнес-процесса всеми необходимыми ресурсами. Обычно владельцы бизнес-процессов назначаются лидером проекта из числа руководителей линейных или функциональных подразделений, на базе которых в последующем предполагается организация процессных подразделений (групп).
Роль владельца бизнес-процесса заключается в том, чтобы быть посредником между группой реинжиниринга и продолжающим функционировать коллективом предприятия.
В частности, владелец бизнес-процесса обеспечивает членов группы реинжиниринга всей необходимой информацией о функционировании предприятия и объясняет работникам предприятия сущность изменяемой технологии работы.
Команды реинжиниринга (группы РБП) разрабатывают проект и выполняют реинжиниринг бизнес-процессов. Число групп реинжиниринга соответствует числу реорганизуемых бизнес-процессов. В состав групп реинжиниринга входят инсайдеры -работники предприятий и их структурных подразделений, участвующих в бизнес-процессе, и аутсайдеры, работники общесистемных подразделений, например отделов информационных технологий, планирования и контроллинга, или внешние консультанты. Среди членов группы реинжиниринга выбирается капитан, который координирует выполнение проектной работы.
В группе реинжиниринга рекомендуется соотношение инсайдеров к аутсайдерам в соотношении 3 : 1 при общей численности группы 7 -1 0 человек. Особенность работы группы реинжиниринга заключается в активном участии всех членов группы, когда не допускаются ситуации, когда аутсайдеры активны, а инсайдеры пассивны (аутсайдеры задают вопросы инсайдерам и формируют проектные решения) или, наоборот, инсайдеры активны, а аутсайдеры пассивны (инсайдеры задают вопросы аутсайдерам, как поступать в той или иной ситуации).
Основной метод работы группы реинжиниринга заключается в коллективной выработке проектных решений путем генерации предложений и их критического обсуждения. При этом роль аутсайдеров заключается в методологическом обеспечении процесса реинжиниринга на основе методик и опыта реинжиниринга в аналогичных областях деятельности. Для формализации и выбора проектных решений используются методы структурного, функционально-стоимостного и динамического моделирования и анализа бизнес-процессов.
На стадии реализации проекта реинжиниринга бизнес-процессов, в частности при создании информационной системы, группа реинжиниринга контролирует выполнение работ со стороны разработчиков информационной системы и, таким образом, берет на себя функции заказчика системы.
На стадии внедрения группа реинжиниринга выполняет функции внешнего тестирования информационной системы и обучения членов процессных групп работе в новых условиях.
Методологический центр («царь» РБП) координирует работу множества групп реинжиниринга и обеспечивает их методологией, инструментарием, типовыми решениями и обычно формируется из представителей общесистемных подразделений предприятия (отделов информационных технологий, планирования и контроллинга) или консалтинговой фирмы.
Методологический центр формируется лидером проекта и подчиняется последнему. Если лидер проекта осуществляет периодическое руководство проектом реинжиниринга, то методологический центр выполняет непрерывное оперативное руководство проектом. Цель работы методологического центра заключается в поиске и реализации общесистемных решений в части стыковки различных бизнес-процессов и распределения общих ресурсов на стадии функционирования.
Основной метод работы методологического центра заключаются в анализе исполнения реорганизуемых бизнес-процессов на основе их моделирования на стадии разработки проекта и изучения статистики, получаемой из функционирующей информационной системы, на стадии внедрения бизнес-процессов. Все противоречия в реорганизуемых бизнес-процессах устраняются путем проведения координационных совещаний на уровне владельцев процессов и групп реинжиниринга.
Руководящий комитет выделяет ресурсы на предприятии для проведения реинжиниринга и контролирует выполнение всех этапов в соответствии с разработанным планом-графиком работ. Таким образом, руководящий комитет – это контрольно-распорядительный орган, возглавляемый лидером проекта.
Источник: libraryno.ru
Этапы реинжиниринга бизнес-процессов, реализация проекта реинжиниринга бизнес-процессов
После определения моделей новой организации бизнес-процессов осуществляется разработка обеспечивающих подсистем, поддерживающих функционирование предприятия в новых условиях.
Для изменения структуры организационно-экономической системы осуществляются:
· разработка организационно-штатной структуры предприятия;
· разработка должностных инструкций;
· разработка системы стимулирования работников;
· подготовка рабочей документации.
Для создания новой информационной системы осуществляются:
· генерация, настройка, программирование и отладка программных модулей;
· разработка и наполнение базы данных;
· установка вычислительного оборудования и системы телекоммуникации.
Для быстрой разработки информационной системы широко используются CASE-средства автоматизации проектирования (см. гл. 13) или средства конфигурации комплексных систем управления ресурсами предприятия (ERP-системы), например R/3, BAAN IV, Oracle Application, «Галактика», БОСС и др. (см. гл. 14). В том и другом случае для разработки оригинального программного обеспечения могут потребоваться средства быстрой разработки приложений (RAD-технология) и языки программирования 4-го поколения (4GL), например АВАР4, JAM и ДР — (см. п. 13.4).
Этап релизации проекта реинжиниринга бизнес-процессов заканчивается составлением в соответствии с принятыми стандартами проектной документации, которая формируется либо с помощью CASE-средств, либо специализированных программных средств. В любом случае должно обеспечиваться качественное оформление проектной документации с включением необходимых графических иллюстраций
Методологии моделирования проблемной области
Воснове реинжиниринга бизнес-процессов и проектирования корпоративной ЭИС лежит моделирование проблемной обмети, необходимость которого во многом обусловлена сложностью организационно-экономической системы и ЭИС с функциональной и системной точек зрения. Под проблемной областью понимается взаимосвязанная совокупность управляемых объектов предприятия (предметная область), субъектов управления, автоматизируемых функций управления и программно-технических средств их реализации.
Для того чтобы получить адекватный проблемной области проект ЭИС в виде системы правильно работающих программ, необходимо иметь целостное, системное представление модели, которое отражает все аспекты функционирования будущей информационной системы. При этом под моделью понимается некоторая система, имитирующая структуру или функционирование исследуемой проблемной области, отвечающей основному требованию-адекватности этой области.
Проведение предварительного моделирования проблемной области позволяет сократить время и сроки проведения проектировочных работ и получить более эффективный и качествен╜ный проект. Без проведения моделирования проблемной области велика вероятность получения некачественной ЭИС, в кото╜рой может быть допущено большое количество ошибок в решении стратегических вопросов, приводящих к экономическим потерям и высоким затратам на последующее перепроектирование системы. Вследствие этого все современные технологии проектирования ЭИС основываются на использовании методологии моделирования проблемной области. Модели дают возможность оценить достоинства и недостатки существующей информационной системы предприятия и построить эффективную архитектуру новой информационной системы,
К моделям проблемных областей предъявляются следующие требования:
формализованность, обеспечивающая однозначное описание структуры проблемной области. Для представления моделей используются нотации различных формальных языков моделирования;
понятность для заказчиков и разработчиков на основе применения графических средств отображения модели;
реализуемость, подразумевающая наличие средств физической реализации модели проблемной области в ЭИС;
обеспечение оценки эффективности реализации модели проблемной области на основе определенных методов и вычисляемых показателей.
Для реализации перечисленных требований, как правило, строится система моделей, которая отражает структурный и оценочный аспекты функционирования .проблемной области. Структурный аспект функционирования ЭИС предполагает построение:
объектной структуры, отражающей состав взаимодействующих в процессах материальных и информационных объектов предметной области;
функциональной структуры, отражающей взаимосвязь функций (действий) по преобразованию объектов в процессах;
структуры управления, отражающей события и бизнес-правила, которые воздействуют на выполнение процессов;
организационной структуры, отражающей взаимодействие организационных единиц предприятия и персонала в процессах;
технической структуры, описывающей топологию расположения и способы коммуникации комплекса технических средств.
Для представления структурного аспекта моделей проблемных областей в основном используются графические методы, которые должны гарантировать представление информации о компонентах системы. Главное требование к графическим методам документирования — простота. Графические методы должны обеспечивать возможность структурной декомпозиции специфи╜каций системы с максимальной’ степенью детализации и согласований описаний на смежных уровнях декомпозиции.
Непосредственно с моделированием связана проблема выбора языка представления проектных решений (нотации), позволяющего как можно больше привлекать будущих пользователей системы к ее разработке. Это язык, с одной стороны, должен делать решения проектировщиков понятными пользователю, с другой стороны, предоставлять проектировщикам средства достаточно формализованного и однозначного определения проектных решений, подлежащих реализации в виде программных комплексов, образующих целостную систему программного обеспечения.
Графическое изображение нередко оказывается наиболее ем╜кой формой представления информации. При этом проектировщики должны учитывать, что графические методы документиро╜вания не могут полностью обеспечить декомпозицию проектных решений от постановки задачи проектирования до реализации программ ЭВМ. Трудности возникают при переходе от этапа анализа системы к этапу проектирования и в особенности к программированию. Отдельная программа может не быть результатом прямой декомпозиции некоторой функции системы: она может выполнять определенную обработку информации для нескольких функций в системе.
Главный критерий адекватности структурной модели проблемной области заключается в функциональной полноте разрабатываемой ЭИС.
Оценочные аспекты моделирования проблемной области связаны с разрабатываемыми показателями эффективности автоматизируемых процессов, к которым относятся:
время решения задач;
стоимостные затраты на обработку данных;
косвенные показатели эффективности, такие, как объемы производства, производительность труда, оборачиваемость капитала, рентабельность и т.д.
Для расчета показателей эффективности ЭИС реализующей модель проблемной области, как правило, используются статические методы функционально-стоимостного анализа (ЛВС) и динамические методы имитационного моделирования.
В основе различных методологий моделирования проблемных областей ЭИС лежат принципы последовательной детализации абстрактных категорий. Обычно модели строятся на трехуровнях: на внешнем уровне (определении требований), на концептуальном уровне (спецификации требований) и внутреннем уровне (реализации требований).
Так, на внешнем уровне модель отвечает на вопрос, что должна делать система, то есть определяется состав основных компонентов системы: объектов, функций, событий, организационных единиц, технических средств. На концептуальном уровне модель отвечает на вопрос, как должна функционировать система? Иначе говоря, определяется характер взаимодействия компонентов системы одного и разных типов. На внутреннем уровне модель отвечает на вопрос: с помощью каких программно-технических средств реализуются требования к системе? С позиции жизненного цикла ЭИС описанные уровни моделей соответственно строятся на этапах анализа требований, логического (технического) и физического (рабочего) проектирования.
Дата добавления: 2018-08-06 ; просмотров: 421 ; Мы поможем в написании вашей работы!
Источник: studopedia.net
