Московский государственный университет печати

Г.Н. Ершова


         

Информационные технологии в книжном деле

Учебное пособие


Г.Н. Ершова
Информационные технологии в книжном деле
Начало
Печатный оригинал
Об электронном издании
Оглавление

Введение

1.

Основные понятия и определения

1.1.

От информации к информационным системам

1.2.

Уровни и виды информационных систем в организации

1.3.

Информационные технологии в управленческой деятельности

1.4.

Вопросы для самоконтроля

2.

Базы данных и Интернет

2.1.

Роль баз данных и файловые системы

2.2.

Основы моделирования данных

2.3.

Концептуальное моделирование структуры базы данных книжного магазина

2.4.

Логическое моделирование базы данных книжного магазина

2.5.

Архитектура многопользовательских СУБД

2.6.

Хранилища данных

2.7.

Интернет

2.8.

Поисковые системы

2.9.

Вопросы для самоконтроля

3.

Внедрение и развитие информационных систем

3.1.

Системный подход в построении информационных систем

3.2.

Общие вопросы разработки информационной системы

3.3.

Жизненный цикл программного обеспечения

3.4.

Этап «Анализ» жизненного цикла информационных систем

3.5.

Современные методы построения моделей бизнес-процессов

3.6.

Вопросы для самоконтроля

4.

Электронный обмен данными в книжной торговле

4.1.

Электронный обмен данными

4.2.

Развитие информационных технологий на предприятиях книжной торговли

4.3.

Международные коммуникативные форматы

4.4.

Сообщение ONIX-формата

4.5.

Использование ONIX в качестве стандарта обмена коммерческой информацией

4.6.

Безопасность электронного обмена данными

4.7.

Вопросы для самоконтроля

5.

Словарь терминов

6.

Примерный перечень тем для обсуждения на практических занятиях по дисциплине «Информационные технологии в книжном деле»

7.

Литература

Указатели
12   указатель иллюстраций
Рис. 4. Состав системы управления Рис. 5. Элементарный графический блок представления процесса в IDEF0 Рис. 6. Контекстная диаграмма бизнес-процесса закупки товара Рис. 7. Обобщенная декомпозиция бизнес-процесса «Управление закупками» Рис. 8. Декомпозиция процесса «Планирование закупок»

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

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

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

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

Система управления предприятием состоит из трех взаимосвязанных подсистем: информационной, управляющей и объекта управления (рис. 4. Рис. 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. Рис. 5. Элементарный графический блок представления процесса в IDEF0) может иметь входы четырех типов:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Перечислите основные аспекты деятельности предприятия, которые являются предметом исследования системного анализа.
  2. Перечислите основные составляющие системы управления предприятием.
  3. Перечислите характерные особенности и свойства системы управления предприятием.
  4. Дайте характеристики трем основным способам разработки информационной системы.
  5. Что такое жизненный цикл программного обеспечения?
  6. Перечислите этапы жизненного цикла программного обеспечения.
  7. Какие вы знаете роли участников проекта создания информационной системы? В чем состоят их задачи?
  8. Какова цель, когда начинается и чем завершается этап анализа жизненного цикла программного обеспечения?
  9. Какие функциональные модели должны быть разработаны на этапе анализа?
  10. Что такое процесс, функция и операция?
  11. В чем состоит структурный подход к моделированию бизнес-процессов?

© Центр дистанционного образования МГУП