≡× МЕНЮ

• Советы
• Программы
• Обзоры
• Рейтинги
• Игры

Разработка и внедрение информационных систем. Эффективность внедрения информационных систем. Опыт практика Виды деятельности процесса внедрения ис

Управление информационными системами

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

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

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

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

Технологические элементы, обеспечивающие функционирование системы:

Информационную модель предметной области;

Кадровые ресурсы, отвечающие за формирование и развитие информационной модели;

Программный комплекс;

Кадровые ресурсы, отвечающие за конфигурирование программного комплекса;

Аппаратно-техническую базу;

Эксплуатационно-технические кадровые ресурсы;

Управленческие элементы, обеспечивающие организацию эксплуатации системы:

Регламент развития информационной модели и правила внесения в нее изменений;

Регламент технической и пользовательской поддержки программного комплекса;

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

Регламент использования программного комплекса и пользовательские инструкции;

Регламент обучения и сертификации пользователей.

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

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

Отсутствие постановки менеджмента на предприятии;

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

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

Сопротивление сотрудников предприятия;

Временное увеличение нагрузки на сотрудников во время внедрения системы;

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

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

Значительная часть проблем проектов внедрения обусловлена довольно типичными ошибками, которые известны, но тем не менее часто повторяются:

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

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

Чрезмерное увлечение реинжинирингом бизнес-процессов и порой неоправданное их подчинение требованиям стандартной функциональности базовой ERP-системы;

Кардинальная переработка базовой функциональности ERP-системы;

Нереалистичные ожидания вследствие неверной оценки экономической эффективности внедрения ERP-системы.

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

Факторы успеха проекта внедрения

Тетодологии внедрения обычно разрабатываются ведущими производителями информационных систем с учетом особенностей их программных продуктов, а также сферы внедрения. Положительная сторона таких стандартов - их практическая направленность. Они представляют собой глубоко проработанные, проверенные, многократно апробированные рабочие инструкции и шаблоны проектных документов. Такие стандарты обычно далеки от теоретических абстракций, ориентированы на особенности конкретных систем, содержат наилучший опыт. Но у стандартов есть и отрицательные стороны: даже методологии, предназначенные для систем, близких по классу, не взаимозаменяемы. Например, методология внедрения системы Microsoft Axapta направлена во многом на управление настройками модулей и доработками; а при внедрении функционально подобных модулей SAP или ORACLE EBS превалирует идеология бизнес-реинжиниринга, при котором организации предлагается изменять свои бизнес-процессы, адаптируя их под "лучший опыт", зафиксированный в системе. В качестве наиболее известных примеров методологий можно привести следующий, далеко не исчерпывающий перечень:

Разработки компании Microsoft - методологии "OnTarget", "MSF (Microsoft Solutions Framework)", "Business Solutions Partner Methodology";

Разработки компании SAP - методологии "Процедурная модель SAP", "ASAP (Accelerated SAP)";

Разработки компании Oracle - комплекс методологий "Oracle Method".

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

Для Заказчика информационной системы основными результатами использования методологии являются:

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

Максимально эффективное использование ресурсов проекта;

Минимизация сроков и затрат на внедрение;

Уменьшение рисков проекта.

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

Появляется методическая база для обучения новых сотрудников стандартным методам внедрения;

Сокращаются внутренние расходы на организацию и реализацию проектов;

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

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

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

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

Данные проектной документации не устаревают;

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

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

Оптимизируются бюджет проекта и график платежей.

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

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

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

Составляющие методологии внедрения

Основные этапы внедрения информационной системы

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

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

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

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

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

3. Выполнение пилотного проекта.

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

4. Адаптация системы на предприятии.

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

5. Опытная эксплуатация ERP_системы.

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

6. Ввод системы в промышленную эксплуатацию.

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

7. Сопровождение промышленной эксплуатации.

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

Первая и самая главная причина провала: некорректно поставленная цель для информационной системы .

Это один из основных вопросов для любого проекта вообще. Заказчик зачастую выбирает цель, которая не имеет к информационной системе никакого отношения, или же зависит от нее незначительно. Примеры: увеличение продаж, занятие большей доли рынка, создание другой культуры управления предприятием и т. д. Но если компания производит товар, спрос на который падает – как тут поможет информационная система? Проблему здесь должно решать подразделение маркетинга. Если нужно изменить культуру предприятия – это вопрос управления персоналом и генерального директора. У некоторых, однако, теплится надежда, что стоит отдать деньги за информационную систему - и проблемы, связанные с организаций бизнеса, решатся сами собой. Обещания продавцов, «впаривающих» дорогие, иностранного производства, многократно проверенные и построенные на «лучших мировых бизнес-практиках» системы лишь укрепляют эту веру. Но на деле компания с неэффективным стилем управления останется неэффективной, только уже с информационной системой. Если на вашу продукцию упал спрос, он тоже не изменится никак. Правда, информационная система позволит вам быстро и точно подсчитать убытки, в том числе и от ее внедрения.

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

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

Даже если предположить, что специалисты-информационщики знают, как следует изменить бизнес-процессы (с логикой у нас порядок), у них все равно нет нужного административного ресурса, да и ожидаемый результат зависит, в первую очередь, не от программного обеспечения. Здесь явно путается следствие и причина. Допустим, есть предприятие А с информационной системой ABC. Предприятие работает стабильно, нет авралов, неразберихи, заказы выполняются в срок, есть планомерная деятельность отлаженного механизма. Можно сделать вывод, что все хорошо благодаря системе ABC, но это 100% не так. Наличие системы ABC у предприятия A, кончено же, вносит свой вклад в бизнес, но не является ключевым. Если руководство некоего предприятия Б решило внедрить у себя систему ABC в надежде, что после ее внедрения предприятие Б тоже будет работать так же, как A, его ждет сюрприз. Деньги будут потрачены, но ожидаемый эффект не наступит, т.к. методика работы на предприятии Б не изменится.

Эффективные цели

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

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

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

Техническое задание

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

Получается, что не заказчик подписал неподходящее ТЗ, а исполнитель разработал и предложил совсем не то – не угадал, о чем мечтал заказчик. Замечаете парадокс? Исполнитель сам для себя пишет ТЗ, но при этом должен угадать, чего на самом деле хочет заказчик. В принципе, это возможно (для участников шоу «Битва Экстрасенсов»), но маловероятно. У меня был опыт создания подробных ТЗ, которые на этапе внедрения претерпевали изменения порядка 30%. Обычная история: в процессе работы над проектом у заказчика появлялись новые идеи, их приходилось учитывать, отказываясь от предыдущих решений. Потому я не сторонник очень подробных ТЗ. Они отнимают много времени, а в итоге будут скорректированы на этапе опытной эксплуатации и внедрения. Если не сделать корректировку, можно испортить отношения с заказчиком. При попытке сослаться на подробное ТЗ в ответ вы услышите – «ну, вы же специалисты, должны были сами все знать заранее».

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

Есть еще один вариант составления ТЗ: в нем декларируется конечная цель заказчика. И тут вы можете сразу заметить противоречия с предыдущем написанным тестом. Это случай составления проекта, в котором информационная система является только частью. У меня был опыт внедрения комплексной системы управления компаний, где основная сумма по контакту выплачивалась в случае, если заказчик получит увеличение оборота в два раза. Спрашивается, это как? Ответ прост: цели заказчика - автоматизация и оптимизация бизнес процессов копании, ускорение процесса работы с клиентами, точный учет затрат по контрактам, точный расчет бонусов менеджерам, участвующим в контрактах, финансовое планирование. Исходя из того, что все эти задачи не были решены, я подписал контракт. К сожалению, достигнуть 100% увеличения объема оборота у заказчика за 1 год не удалось, но 83% тоже хорошо. Мое вознаграждение было выплачено пропорционально.

Следующим важным документом для успешного выполнения работ является план-график работ.

План-график работ

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

Запуск системы в работу

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

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

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

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

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

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

Теги: Добавить метки

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Подобные документы

Особенности проектирования информационных систем основанных на базах данных. Использование CASE-средств и описание бизнес процессов в BP-Win. Этапы проектирования современных информационных систем, виды диаграмм и визуальное представление web-сайта.

курсовая работа , добавлен 25.04.2012


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

дипломная работа , добавлен 20.07.2014


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

курсовая работа , добавлен 14.11.2017


Понятие CASE-средств как программных средств, которые поддерживают процессы создания и сопровождения информационных систем (ИС). Особенности IDEF-технологии разработки ИС. Описание нотации IDEF0. Разработка функциональных моделей бизнес-процесса.

презентация , добавлен 07.04.2013


Обзор принципов построения и эффективного применения систем управления базами данных, CASE-средств автоматизации проектирования. Анализ возможностей методологии и инструментальных средств. Разработка модели бизнес-процессов гостиницы в среде All Fusion.

курсовая работа , добавлен 28.12.2012


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

курсовая работа , добавлен 14.03.2011


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

курсовая работа , добавлен 07.04.2015


Роль инструментальных средств проектирования в создании информационной системы. Преимущества CASE-средств разработки Bpwin и Erwin, системы поиска, исправления ошибок модели данных Model Validator. Разработка модели процессов документооборота предприятия.

контрольная работа , добавлен 24.06.2012

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

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

Для системы управления предприятием основными аспектами являются следующие факторы:

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

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

Для информационных систем управления предприятием характерны следующие особенности и свойства:

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

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

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

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

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

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

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

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

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

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

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

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

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

Каждый из способов создания ИС имеет свои преимущества и недостатки. Они приведены в таблице 4.

Таблица 4. Преимущества и недостатки различных способов создания ИС

Способ создания информационной с

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Следующим этапом разработки является этап проектирования, имеющий цели:

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

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

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

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

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

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

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

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

Завершающими этапами являются эксплуатация и сопровождение.

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

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

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

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

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

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

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

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

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

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

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

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

Остановимся более подробно на структурном подходе к моделированию бизнес-процессов, в основе которого лежит метод структурного анализа или SADT-методология (Structured Analysis and Design Technique - технология структурного анализа и проектирования). Первоначально метод SADT применялся для моделирования технологических процессов. В 1970-х годах он стал использоваться вооруженными силами США, после чего в 1993 году был принят в качестве федерального стандарта США под наименованием IDEF0 (Integration computer aided manufacturing Definition).

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

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

В SADT-диаграммах используется всего два графических элемента:

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

Каждый блок (рис. 5. ) может иметь входы четырех типов:

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

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

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

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

Контекстная диаграмма процесса закупки приведена на рис. 6.

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

Декомпозиция процесса «Управление закупками» может быть представлена следующими задачами:

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

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

На рис. 7. изображена декомпозиция бизнес-процесса «Управление закупками», построенная с использованием одного из таких CASE-средств - BPwin (разработчик PLATINUM technology).

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

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

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

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