Реинжиниринг бизнес – процессов.

↑

⇐ ПредыдущаяСтр 16 из 17Следующая ⇒

Модели жизненного цикла КИС

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

· каскадная модель (70-85 г.г.);

· спиральная модель (86-90 г.г.).

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

Рис.1. Каскадная модель разработки КИС

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

Достоинства применения каскадного подхода:

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

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

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

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

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

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

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

В основе спиральной модели жизненного цикла лежит при­менение типовой технологии или RAD-технологии (Rapid Application Development - технологии быстрой разработки приложений). Согласно этой технологии КИС разрабатывает­ся путем расширения программных прототипов, повторяя путь от детализации требований к детализации программного кода. Естественно, что при типовой технологии сокращается чис­ло итераций и меньше возникает ошибок и несоответствий, ко­торые необходимо исправлять на последующих итерациях, а само проектирование КИС осуществляется более быстрыми темпами, упрощается создание проектной документации. Для более точ­ного соответствия проектной документации разработанной КИС все большее значение придается ведению общесистемного репозитория и использованию CASE-технологий (Computer Aided Software Engineering). Под термином CASE понимаются программные средства, поддерживающие процессы создания и сопровождения КИС , включая анализ и формулировку требований, проектирование прикладного программного обеспечения и баз данных, генерацию кода, тестирование, документирование и управление проектом. 

Жизненный цикл при использовании RAD-технологии пред­полагает активное участие на всех этапах разработки конечных пользователей будущей системы и включает четыре стадии информационного инжиниринга (рис.2):

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

• проектирование. Пользователи принимают участие в техническом проектировании под руководством специалистов-разработчиков;

• конструирование. Специалисты-разработчики проектируют рабочую версию КИС с использованием языков 4-го поколения;

• внедрение. Специалисты-разработчики обучают пользователей работе в среде новой КИС.

Рис 2. Спиральная модель ЖЦ

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

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

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

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

Этапы проектирования КИС.

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

Можно выделить следующие стадии создания КИС.

Стадия 1. Формирование требований:

Ø обследование объекта и обоснование необходимости создания КИС;

Ø формирование требований пользователей к КИС;

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

Стадия 2. Разработка концепции:

Ø изучение объекта автоматизации;

Ø проведение необходимых научно-исследовательских работ;

Ø разработка вариантов концепции КИС, удовлетворяющих требованиям пользователей;

Ø оформление отчета и утверждение концепции.

Стадия 3. Техническое задание:

Ø разработка и утверждение технического задания на создание КИС.

Стадия 4. Эскизный проект:

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

Ø разработка эскизной документации на КИС и ее части.

Стадия 5. Технический проект:

Ø разработка проектных решений по системе и ее частям;

Ø разработка документации на КИС и ее части;

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

Ø разработка заданий на проектирование в смежных частях проекта.

Стадия 6. Рабочая документация:

Ø разработка рабочей документации на КИС и ее части;

Ø разработка и адаптация программ.

Стадия 7. Ввод в действие:

Ø подготовка объекта автоматизации;

Ø подготовка персонала;

Ø комплектация КИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);

Ø пусконаладочные работы;

Ø проведение предварительных испытаний;

Ø проведение опытной эксплуатации;

Ø проведение приемочных испытаний.

Стадия 8. Сопровождение:

Ø выполнение работ в соответствии с гарантийными обязательствами;

Ø послегарантийное обслуживание.

В процессе оценки текущей деятельности предприятия в интересах формирования требований к КИС необходимо постоянно проводить сравнение двух возможных состояний:

· состояние - «как есть» («as is»), представляющее собой реальную картину состояния дел в корпорации на момент обследования (организационно-штатная структура, существующие бизнес – процессы, используемые технологии и т.д.). Анализ данного состояния позволяет критически оценить деятельность и выявить узкие места в существующих бизнес – процессах;

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

В общем случае переход из состояния «as is» в состояние «to be» может быть осуществлен как эволюционным путем (последовательная автоматизация отдельных сфер деятельности и постепенная реорганизация бизнес – процессов), так и революционным путем (создание новых бизнес - процессов). Непрерывные и довольно существенные изменения в технологиях, рынках сбыта и потребностях клиентов сегодня становятся обычным явлением, и компании, стремясь сохранить свою конкурентоспособность, вынуждены непрерывно перестраивать корпоративную стратегию и тактику, прибегая к революционным преобразованиям.

Революционный путь развития достигается использованием концепции BPR (Business Process Reengineering – реинжиниринг бизнес – процессов).

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

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

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

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

1. Дисфункциональность (Осуществление каких процессов сопряжено с наибольшими трудностями?).

2. Значимость (Какие процессы оказывают наибольшее воздействие на клиентов компании?).

3. Осуществимость (Какие из происходящих в компании процессов могут быть перепроектированы в данный момент наиболее успешно?).

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

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

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

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

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

- рационализация бизнес - операций, входящих в состав преобразу­емого бизнес – процесса. Предполагается оптимизация процедур, ставших «узким ме­стом» деятельности предприятия. 

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

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

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

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

Во всех методиках реин­жиниринга во главе угла лежит искусство команды, осуществляющей реинжиниринг.

Познавательные статьи:



Техника прыжка в длину с разбега

Организация работы процедурного кабинета

Области применения синхронных машин

Оптимизация по Винеру и Калману