1. Текст лекций по теме &quot

Перечень вопросов к зачету:
1. Информационное общество. Определение, основные черты.
2. Информационные ресурсы. Уровни информационных ресурсов в управлении
экономическими процессами.
3. Информационные ресурсы в управлении экономическими процессами на
общегосударственном (макро) уровне.
4. Цели и задачи обеспечения информационными ресурсами для макроэкономического
мониторинга.
5. Цели и задачи обеспечения информационными ресурсами для обеспечения
экономической безопасности.
6. Информационные ресурсы в управлении социальной и общественно-политической
сферами.
7. Понятие информационной технологии и ее виды. Классификация прикладных
информационных технологий.
8. Информационные системы. Открытые информационные системы.Профили
информационных систем.
9. Понятие информационного менеджмента.
10. Консоль управления Microsoft (Microsoft Management Console, MMC) назначение.
11. Оснастки консоли управления Microsoft (Microsoft Management Console, MMC).
12. Типы сетевых подключений. Локальное подключение.
13. Виртуальные частные сети.
14. Телефонные (коммутируемые) подключения. Прямые подключения. Входящие
подключения
15. Используемые протоколы и методы доступа.
16. Службы Asynchronous Transfer Mode (ATM, асинхронный режим передачи).
17. Консалтинг. Основные цели разработки консалтинговых проектов.
18. Этапы разработки консалтинговых проектов.
19. Проведение обследования при выполнении консалтинговых проектов.
20. Анкетирование и интервьюирование при проведении обследования предприятия.
21. Сбор документов при проведении обследования предприятия.
22. Этапы проектирования информационных систем.
23. Технологии проектирования информационных систем.
24. Системная интеграция при проектировании информационных систем.
25. Виды моделей, используемые при проектировании информационных систем.
26. Проектирование ПО с помощью CASE-систем. Спецификации моделей информационных
систем.
27. Методики функционального моделирования.
28. Этапы разработки информационной модели. Классическое проектирование
информационных систем.
29. Объектно-ориентированный подход к анализу и проектированию экономических
информационных систем.
30. Прецеденты в унифицированном процессе компании Rational (Rational Unified Process—
RUP). Итеративность и инкрементность в унифицированном процессе RUP создания
экономических информационных систем.
31. Категории рисков в проектах разработки программного обеспечения.
32. Фазы жизненного цикла унифицированного процесса.
33. Технологические процессы в унифицированном процессе RUP создания экономических
информационных систем.
34. Концепция планирования потребности в материалах MRP.
35. Концепция планирования производственных ресурсов MRP II.
36. Концепция планирования ресурсов всего предприятия ERP. Подсистемы модели
MRP/ERP.
37. Business Management Systems (BMS) – системы управления бизнесом.
38. Стандарт CSRP (Customer Synchronized Resource Planning).
39. Уровни непрерывного улучшения бизнес-процессов (BPI)
40. Критерии управляемости процессов и их соответствие уровням BPI.
41. Критерии оценки «Качества готовой продукции» для уровней BPI.
42. Цикл BPI - балансировка и внутренняя рационализация (переход с I уровня на II).
43. Цикл BPI - объединение с поставщиками (переход с II уровня на III).
44. Цикл BPI - рационализация и развитие клиентов (переход с III уровня на IV).
45. Цикл BPI - одержимость качеством (переход с IV уровня
на V).
46. Ключевые процессы и экономический эффект перехода
на II-й уровень BPI.
47. Понятие аутсорсинга информационных систем.
48. Глобальный аутсорсинг.
49. Модель аутсорсинга.
50. Назначение и свойство хранилищ данных.
51. Архитектура хранилищ данных.
52. Назначение корпоративных порталов.
53. Преимущества использования корпоративных порталов.
54. Обеспечение безопасности в корпоративных порталах.
ТЕКСТ ЛЕКЦИЙ ПО ДИСЦИПЛИНЕ
«ИНФОРМАЦИОННЫЙ МЕНЕДЖМЕНТ»
ДОЛЖЕНКО А.И.
ИНФОРМАЦИОННОЕ ОБЩЕСТВО И КОМПОНЕНТЫ
ИНФОРМАЦИОННОГО МЕНЕДЖМЕНТА
В любом государстве принципиально важно создать условия беспрепятственного движения по всей территории не
только товаров и людей, но и информации. Есть все основания утверждать, что создание информационного общества
(единого информационного пространства) для государства является таким же необходимым условием, как и сохранение
его целостности.
Информационное пространство — совокупность информационных ресурсов, информационных систем и
коммуникационной среды.
Единое информационное пространство представляет собой совокупность баз и банков данных, технологий их
ведения и использования, информационно-телекоммуникационных систем и сетей, функционирующих на основе
единых принципов и по общим правилам, обеспечивающим информационное взаимодействие организаций и граждан, а
также удовлетворение их информационных потребностей. Иными словами, единое информационное пространство
складывается из следующих главных компонентов:
• информационных ресурсов, содержащих данные, сведения и знания, зафиксированные на соответствующих
носителях информации;
• организационных структур, обеспечивающих функционирование и развитие единого информационного
пространства, в частности сбор, обработку, хранение, распространение, поиск и передачу информации;
• средств информационного взаимодействия граждан и организаций, в том числе программно-технических средств и
организационно-нормативных документов, обеспечивающих доступ к информационным ресурсам на основе
соответствующих информационных технологий.
Информационное общество
Информационное общество (Information society) — концепция постиндустриального общества; новая историческая
фаза развития цивилизации, в которой главными продуктами производства являются информация и знания.
Отличительные черты информационного общества:
• увеличение роли информации и знаний в жизни общества;
• возрастание доли информационных коммуникаций, продуктов и услуг в валовом внутреннем продукте;
• создание глобального информационного пространства, обеспечивающего:
- эффективное информационное взаимодействие людей;
- их доступ к мировым информационным ресурсам;
-удовлетворение их потребностей в информационных продуктах и услугах.
Целевое направление информационного менеджмента — создание нового информационного общества.
В июне 2000 г. на встрече G8 была принята Окинавская Хартия Глобального информационного общества.
«Информационное общество, как мы его представляем, позволяет людям шире использовать свой потенциал и
реализовывать свои устремления. Для этого мы должны сделать так, чтобы информационные технологии служили
достижению взаимодополняющих целей обеспечения устойчивого экономического роста, повышения общественного
благосостояния, стимулирования социального согласия и полной реализации их потенциала в области укрепления
демократии, транспарентного и ответственного управления международного мира и стабильности» (Из Окинавской
декларации информационного общества).
В Российской Федерации объявлена федеральная целевая программа «Электронная Россия на 2002—2010 годы», в
соответствии с которой в 2003—2007 гг. в России будет реализована информатизация правительственных органов, а в
2007-2008 гг. будет завершен переход на электронный документооборот федеральными органами власти и органами
власти субъектов Федерации и муниципальных образований.
В
целом
распространение
новых
информационно-коммуникативных
технологий
действительно
стало
доминирующим фактором, определяющим ускорение процессов социальной трансформации общества. Однако вектор
этой трансформации лишь отчасти детерминирован и в значительной степени зависит от целенаправленных усилий
людей. Новые технологии создают лишь новые возможности, спектр которых постоянно расширяет поле выбора
каждого отдельного человека.
Информатизация — лишь одна из важнейших тенденций общественного развития, сопровождающая переход к
новой постиндустриальной, постэкономической цивилизации, связанных и со значительным ростом доходов в
большинстве развитых стран мира за последние десятилетия, и с принципиальным увеличением доли лиц, получивших
высшее образование. На стыке изменений в коммуникационных технологиях в мотивации человеческой деятельности
нашими общими усилиями продолжает формироваться информационное общество текущего XXI в.
Создание нового информационного общества возможно сегодня только на базе технологий информационного
менеджмента, включая автоматизированные информационные системы как базовый компонент информационного
менеджмента и информационного общества.
Информационные ресурсы
Понятие информационного ресурса.
Информационный ресурс — организованная совокупность документированной информации, включающая базы
данных и знаний, другие массивы информации в информационных системах (библиотеки, архивы, делопроизводство и
т.д.).
К ним относятся рукописные, печатные и электронные издания, содержащие нормативную, распорядительную и
другую информацию по различным направлениям общественной деятельности (законодательство, политика, социальная
сфера и т.д.). Перенесенные на электронные носители информационные ресурсы с помощью средств вычислительной
техники и связи приобретают качественно новое состояние, становятся доступными для оперативного воспроизводства
необходимой информации и превращаются в важнейший фактор социально-экономического развития общества.
Информационный ресурс — базовая составляющая информационного менеджмента.
Формирование информационных ресурсов и их грамотное системное использование во все большей степени
становятся объектом политических и экономических интересов как на национальном, так и на международном уровнях.
Такими интересами объясняется глобальная конкуренция за господство на информационном рынке, приведшая к
стремительным темпам роста телекоммуникационных систем и информационных технологий. При этом огромные
средства выделяются ежегодно на разработку технологий работы с информационными ресурсами. По данным «Financial
Times», за 1998 г. в числе 500 крупнейших компаний мира более 20% составляют компании, специализирующиеся в
области создания и непосредственного использования информационных ресурсов.
Государство
на
основе
грамотного
системного
использования
информационных
ресурсов
всех
сфер
жизнедеятельности обеспечивает:
• поступательное развитие производительных сил общества и высокий уровень жизни граждан;
• национальную безопасность;
• защиту прав и свобод личности.
Проблемы
обеспечения
информационными
ресурсами.
Особо
выделяются
проблемы
обеспечения
информационными ресурсами управления экономическими процессами, национальной безопасностью, социальной и
общественно-политической сферами
Информационные ресурсы в управлении экономическими процессами охватывают:
• общегосударственный (макро) уровень;
• отраслевой уровень;
• территориальный уровень;
• уровень экономических агентов.
Задачи и цели управления на каждом из уровней определяют состав и объем необходимых информационных
ресурсов и способы их использования.
На общегосударственном уровне управления решаются задачи:
• макроэкономического мониторинга, анализа и прогнозирования;
• обеспечения экономической безопасности;
• контроля за деятельностью органов государственного, местного и отраслевого управлений.
Обеспечение экономической безопасности государства включает в себя предотвращение острых кризисных явлений
в экономике, защиту экономических интересов и борьбу с экономическими преступлениями.
Это реализуется оперативным мониторингом:
• хозяйственной деятельности экономических агентов и сферы индивидуального потребления;
• уровня доходов и потребления граждан;
• движения денежных средств в валюте;
• информационных ресурсов банковской сети, Государственного таможенного комитета, Национального банка,
железной дороги и других транспортных организаций.
Эффективная борьба с экономическими преступлениями обеспечивается более детальной оперативной информацией
о финансовой и хозяйственной деятельности предприятия, позволяющей выявить аномалии в экономическом поведении.
Мониторинг за хозяйственной деятельностью предприятий требует оперативного доступа к соответствующим
информационным ресурсам. Система контроля за деятельностью органов государственно-местного и отраслевого
управления обеспечивает анализ качества исполнения возложенных на них функций, расходования выделяемых на их
нужды бюджетных средств, выявления и пресечения нарушений законодательства.
На отраслевом уровне управления решаются задачи обеспечения научно-технического прогресса, повышения
производительности труда, качества продукции, роста объема производства. Решение этих задач обеспечивается
следующими типами информационных ресурсов: научно-техническим, маркетинговым и нормативно-справочным.
На территориальном уровне задачи управления и требования к информационным ресурсам аналогичны задачам
общегосударственного уровня.
Информационные ресурсы в области национальной безопасности должны обеспечить предотвращение оперативных
и стратегических угроз национальной безопасности:
• внезапных кризисов в жизненно важных отраслях (энергетика, транспорт, банковская система и др.), вызванных в
том числе забастовками;
• социальных взрывов, обусловленных ростом безработицы и падением жизненного уровня;
• прихода к власти криминальных или экстремистских группировок;
• перехода под контроль иностранного капитала жизненно важной части национальных ресурсов;
•
разрушения национальной науки и культуры, снижения образовательного и культурного уровня населения,
распространения идеологии насилия, различных сектантских религиозных течений;
• утечки за границу финансовых, интеллектуальных и информационных ресурсов;
• банкротства на государственном уровне, вызванного резким ростом внутреннего и внешнего долга;
• потери стратегических интересов в международном сообществе.
Информационные ресурсы в управлении социальной и общественно-политической сферами обеспечивают решение
следующих задач:
• социальное измерение, регулирование и уменьшение социальной расслоенности и напряженности в обществе;
•
социальная защита населения (пенсионное страхование, социальное страхование, страхование на случай
безработицы, страхование от несчастных случаев на производстве и профзаболеваний и т.д.);
• анализ и управление общественным мнением;
• защита национального информационного и культурного пространства;
• развитие культурно-образовательного уровня населения.
Основной ресурс (элемент) общественной системы, состояние которого обеспечивается информационным ресурсом
в социально-политической сфере, — это человеческий ресурс. Основное назначение информационного ресурса в данной
сфере — обеспечить социальную защиту, а также необходимый для развития общества культурный, образовательный и
политический уровень населения. Основные источники информации о состоянии человеческих ресурсов:
• данные индивидуального (персонифицированного) учета в системе государственного социального страхования;
• данные переписи населения;
• выборочное обследование домашних (семейных) хозяйств;
• опросы общественного мнения;
• социальные измерения (уровень потребления, доходов и сбережений по категориям населения, индексы
потребительских цен, прожиточный минимум, стоимость потребительской корзины и т.п.).
В заключение можно сделать следующие основные выводы:
1) формирование и использование информационных ресурсов — одна из ключевых проблем создания единого
информационного пространства любого государства;
2) информационные ресурсы создаются в процессе функционирования автоматизированных информационных
систем всех сфер жизнедеятельности государства:
• органов власти и управления;
• органов местного самоуправления;
• юридических лиц;
• физических лиц.
Информационные технологии
Понятие информационной технологии и ее виды. Информационная технология — совокупность методов,
способов, приемов и средств обработки документированной информации, включая прикладные программные средства и
методологию их применения.
Информационная технология предназначены для реализации информационных процессов в соответствии с
заданными требованиями. Они являются базовыми инструментми информационного менеджмента.
Анализ рынка информационных компонентов позволяет распределить перечень информационных технологий на два
обширных класса — базовые информационные технологии и прикладные информационные технологии. Причем
граница этого деления является условной.
Базовые информационные технологии — это технологии, которые реализуются на уровне взаимодействия
элементов вычислительных систем. К этому классу относятся следующие основные системы.
Операционные системы. Технологии управляют непосредственно работой средств вычислительной техники. Для
класса машин общего назначения (mainframe) — ОС ЕС, СВМ, MVS. Для персональных компьютеров на базе
универсальных процессоров INTEL — MS DOS. Windows, UNIX-системы и др. Для локальных сетей — сетевые
операционные системы Novell, Windows NT и др.
Языки программирования. В развитие классических процедурных языков программирования — Fortran, Cobol, С,
Pascal в последние годы появились их объектно-ориентированные расширения с интегрированными средами разработки
– Visual Basic, Visual C++, Java, C# и другие. В настоящее время в связи с бурным началом использования Internetтехнологий все большее использование получает язык Java.
Технологии архитектуры «клиент-сервер». Технологии реализуются в корпоративных системах на основе
локальных сетей на основе разделения функций обработки, управления сетью, хранения данных, обеспечения внешних
связей и т.д. на специально предназначенных для этого компьютерах (серверах). Эти технологии реализованы
практически во всех используемых в настоящее время программных продуктах.
Технологии многопроцессорной обработки. Данные технологии на основе специализированных персональных
ЭВМ наращивают мощности этих машин (масштабирование) за счет расширения их вычислительной структуры. К
этому классу относятся серверы с симметричным мультипроцессированием (SMP-серверы).
Технологии нейровычислений. Они эффективно реализуют определенные виды сложной обработки информации на
специально созданных программно-технических устройствах, входящих в состав персональных ЭВМ и работающих по
принципам нейронных сетей.
Технологии автоматизированного проектирования (CASE-технологии). Технологии позволяют осуществлять
разработку систем информатизации, практически не используя для этих целей языки программирования.
Телекоммуникационные технологии. Технологии дают возможность обеспечить взаимодействие в сетях на основе
единых правил. Этот класс — весьма широкий и обеспечивает реализацию таких стандартов, как ISO/OSI, EDIFACT,
X.500 и др.
Базовые технологии Internet. Среди наиболее широко используемых технологий — электронная почта, служба ftp
(пересылка файлов), технология формирования информационных серверов на Основе гипертекстовых документов
(WWW) и др.
Intranet-технологии. Они позволяют строить ведомственные (корпоративные) системы информатизации на основе
базовых технологий Internet.
Технологии обработки текстов. Эти технологии наиболее широко используются и уже позволили наладить во
многих организациях электронную подготовку корреспонденции. Они выступают элементами систем электронного
документооборота и требуют унификации.
Системы управления базами данных (СУБД). Эти технологии предназначены для хранения и обеспечения
эффективного доступа к массивам информации. Для реализации систем различного масштаба применяются СУБД,
поддерживающие язык запросов SQL и эффективно реализующие передовые технологии обработки. Наиболее широкое
использование получают такие СУБД, как Oracle, SQL Server.
Технологии информационных хранилищ. Они обеспечивают хранение и обработку больших массивов разнородной
информации и, как правило, строятся на основе уже апробированных СУБД, значительно расширяя их возможности.
Экспертные системы (ЭС). Технологии позволяют на основе определенных правил вывода осуществлять анализ
информационного описания объектов и вырабатывать на основе этих правил соответствующие заключения. Эти
технологии — базовые для систем представления знаний.
Геоинформационные
технологии
(ГИС).
Технологии
позволяют
осуществлять
обработку
графической
информации: карты, планы городов, космо- и аэроснимки, данные дистанционного зондирования земной поверхности,
чертежи и т.п.
Мультимедиа-технологии и технологии создания виртуальной реальности. Эти системы осуществляют
совместную обработку текстовой, графической информации, звука, изображений. Технологии виртуальной реальности
дают возможность моделировать в динамике пространственное представление объектов.
Технологии цифроаналоговых преобразований. Они позволяют осуществлять преобразования данных из цифрового
в аналоговый вид и обратно, что позволяет производить компьютерную обработку получаемой от приборов информации
и выдавать соответствующие управляющие решения.
Технологии криптозащиты. Эти технологии осуществляют по специальным алгоритмам преобразование
информации, которая становится доступной только обладающему соответствующими ключами субъекту. Их разработка
и применение должны регламентироваться соответствующими государственными службами.
Технологии человеко-машинного интерфейса. Обеспечивают унификацию действий человека при взаимодействии
с различными видами вычислительных средств. Предложенные базовые информационные технологии позволяют
формировать программно-технические решения по созданию интегрированных систем информатизации субъектов,
реализации телекоммуникационной среды, обеспечивающей взаимодействие этих систем.
Классификация прикладных информационных технологий. Прикладные информационные технологии — это
технологии, реализующие типовые процедуры обработки информации в конкретных предметных областях.
Предлагается следующая условная классификация:
• по реализации информационных ресурсов;
• в системах массового обслуживания населения;
• в процессах экоинформатизации;
• в сфере организационного управления;
• в сфере интеллектуального потенциала;
• в производственных процессах;
• по поддержке управляющих решений в социальной, политической, экономической сферах и безопасности
государства.
Информационные технологии в производственных процессах, например, можно подразделять на следующие
основные подклассы:
• интегрированные автоматизированные системы управления;
• информационно-аналитические системы координации деятельности предприятий;
• автоматизированные системы управления предприятиями;
• системы автоматизированного проектирования;
• автоматизированные системы управления технологическими системами;
• автоматизированные системы управления гибкими производственными системами.
В заключение отметим, что рассмотренные выше информационные технологии позволяют формировать
программно-технические решения по созданию автоматизированных информационных систем субъектов, реализации
телекоммуникационной среды, обеспечивающей взаимодействие этих систем, и, следовательно, содействуют созданию
единого информационного пространства.
Информационные системы
Система — это совокупность взаимосвязанных элементов, то, из чего образованы системы, называется элементом до
тех пор, пока имеет какую-либо связь с системой.
Взаимосвязь элементов системы обусловливает ее целостность. Если элемент системы теряет связь с системой, то он
превращается в новую систему. Точно так же, как и другая часть системы превращается в новую систему.
Информационная система — организованная совокупность информационных технологий, объектов и отношений
между ними, образующая единое целое (СТБ 982-94).
Информационная система (Information System) — системы обработки информации в совокупности с
относящимися к ней ресурсами организации, такими, как люди, технические и финансовые ресурсы, которая
предоставляет и распределяет информацию (ГОСТ ИСО/МЭК 2382-1-99).
Информационные системы всех видов — база для продуктивной работы менеджера любого уровня и во всех
предметных областях, т.е. базовая компонента информационного менеджмента.
Открытые информационные системы. Ход развития информационных технологий в развитых странах мира за
последние 40 лет позволяет сделать вывод, что мировое сообщество переходит на технологии создания открытых
информационных систем.
Открытая система (Open System) — это система, реализующая открытые спецификации (стандарты) на
интерфейсы, службы и форматы данных, достаточные для того, чтобы обеспечить:
• возможность переноса (переносимость) прикладных систем разработанных должным образом, с минимальными
изменениями, на широкий диапазон систем (на различные платформы);
•
совместную работу (масштабируемость) с другими прикладными системами на локальных и удаленных
платформах в целях расширения ее функциональных возможностей и (или) придания системе новых качеств;
• взаимодействие с пользователями в стиле, облегчающем последним переход от системы к системе (мобильность
пользователей).
Основы технологии открытых систем. Необходимость развития вычислительных сетей привела к тому, что
оказались наиболее востребованными работы по взаимодействию открытых информационных систем, в то время как
проблема
переносимости
программ
не
решалась
столь
успешно.
Эти
два
качества
—
1) взаимодействие открытых систем и 2) переносимость программ — составляют основу технологии открытых систем.
Впервые эти качества были реализованы на практике при создании компьютеров серии IBM 360, обладающих единым
набором команд и имеющих одну и ту же операционную систему.
Частичное решение проблемы мобильности для программ и программистов обеспечили ранние стандарты языков,
например Фортрана и Кобола. Языки позволяли создавать переносимые программы, хотя зачастую и ограничивали их
функциональные возможности. Мобильность обеспечивалась также за счет того, что эти стандарты были приняты
многими производителями. Когда языки приобрели статус стандарта де-факто, их разработкой и сопровождением
начали заниматься национальные и международные организации по стандартизации. Далее языки развивались уже
независимо от своего создателя. Достижение определенного уровня мобильности программного обеспечения можно
считать первым примером истинных возможностей открытых систем.
Таким образом, технология открытых систем решает проблему создания единого информационного пространства
как в рамках одной страны, так и во всем мире.
Профили информационных систем. Информационные системы создаются в процессе информатизации всех
основных сфер современного общества:
• органов государственного управления (законодательной и исполнительной власти республиканского уровня,
управления хозяйством на уровне областей);
• финансово-кредитной сферы (банков и финансово-промышленных групп);
• информационного обслуживания предпринимательской деятельности;
• производственной сферы (интегрированные производственные системы);
• науки и научного обслуживания;
• социальной сферы;
• образования;
• здравоохранения;
• информационного обслуживания населения и т.д.
Развитие и применение открытых информационных систем неразрывно связано с применением стандартов
информационных технологий. Основой применения этих стандартов в настоящее время стала методология
функциональной стандартизации информационных технологий.
При создании и развитии сложных, распределенных, тиражируемых информационных систем требуется гибкое
формирование и применение совокупностей базовых стандартов и нормативных документов разного уровня, выделение
в них требований и рекомендаций, необходимых для реализации данных функций ИС. Для унификации и
регламентирования реализации заданных функций ИС такие совокупности базовых стандартов должны адаптироваться
и конкретизироваться применительно к определенным классам проектов, функций, процессов и компонентов ИС. В
связи с этой потребностью выделилось и формировалось понятие «профилей» ИС как основного инструмента
функциональной стандартизации.
Профиль — это совокупность нескольких (или подмножество одного) базовых стандартов (и других нормативных
документов) с четко определенными подмножествами обязательных и факультативных возможностей, предназначенная
для реализации заданной функции или группы функций.
Функциональная характеристика (заданный набор функций) объекта стандартизации определяет процесс
формирования и применения профиля конкретного объекта или процесса. В профиле выделяются и устанавливаются
допустимые факультативные возможности и значения параметров каждого базового стандарта и (или) нормативного
документа, входящего в профиль. Профиль не может противоречить использованным в нем базовым стандартам и
нормативным документам. Он должен использовать выбранные из альтернативных вариантов факультативные
возможности и значения параметров в пределах допустимых. На базе одной и той же совокупности базовых стандартов
могут формироваться и утверждаться различные профили для разных проектов ИС и сфер применения. Эти ограничения
базовых документов профиля и их гармонизация, проведенная разработчиками профиля, должны обеспечивать качество,
совместимость и корректное взаимодействие компонентов системы, соответствующих профилю, в заданной области
применения профиля.
Базовые стандарты ИТ и профили ИС в зависимости от проблемно-ориентированной области применения ИС могут
использоваться как непосредственные директивные, руководящие или как рекомендательные документы, а также как
нормативная база, используемая при выборе или разработке средств автоматизации технологических этапов или
процессов создания, сопровождения и развития ИС.
В зависимости от области распространения профилей они могут иметь разные категории и соответственно разные
статусы утверждения:
• профили конкретной ИС, определяющие стандартизованные проектные решения в пределах данного проекта и
являющиеся частью проектной документации — функциональные профили;
• профили ИС, предназначенные для решения некоторого класса прикладных задач, которые распространяются на
все ИС данного класса в пределах предприятия, отрасли, региона или страны и утверждаются как стандарты
предприятий, ведомственные или государственные (правительственные) стандарты — профили государственного
значения.
Следует рассматривать две группы функциональных профилей ИС:
1) профили, регламентирующие архитектуру и структуру ИС и ее компонентов (функции, интерфейсы и протоколы
взаимодействия, форматы данных и т.д.);
2) профили, регламентирующие процессы проектирования, разработки, применения, сопровождения и развития ИС
и их компонентов.
Профили ИС унифицируют и регламентируют только часть требований, характеристик, показателей качества
объектов и процессов, выделенных и формализованных на базе стандартов и нормативных документов. Другая часть
функциональных и технических характеристик ИС определяется заказчиками и разработчиками творчески, без учета
положений нормативных документов.
Информационный менеджмент — технология организации управленческой деятельности
Менеджмент (управление) — это процесс, направленный на достижение целей организации посредством
упорядочения преобразований исходных субстанций или ресурсов (труда, материалов, денег, информации и т.п.) в
требуемые результаты (изделия, услуги). Как известно, менеджеры воздействуют прежде всего на главный элемент
организации — людей, координируя их деятельность. Эффективность менеджмента определяется как соотношение
результатов работы и использованных для их получения ресурсов.
Теорию (научную дисциплину) менеджмента можно охарактеризовать как аккумулированные и по определенным
правилам логически упорядоченные знания, представляющие собой систему принципов, методов и технологий
управления, разработанных на основе информации, полученной как эмпирическим путем, так и в результате
исследований в различных областях науки.
Теория менеджмента отличается следующими особенностями:
• ориентирована на решение практических задач;
• имеет междисциплинарный характер;
• разрабатывается в международном масштабе.
Менеджмент предназначен для решения практических задач. Он нацелен на исследование и разработку правил
эффективного управления с целью достижения высоких результатов, являющихся критерием его качества. Отсюда
вытекают следующие требования к теории менеджмента:
1) она должна предоставлять работникам, занятым практической деятельностью, знания, помогающие им повысить
уровень управления;
2) способствовать повышению квалификации менеджеров и особенно подготовке претендентов на эти должности;
3) определять области и проблемы, требующие дальнейшей изучения и разработки в целях содействия развитию
познавательной базы.
Технология — это формализованное описание деятельности включающее набор ресурсов, инструментов, приемов их
использования, и способов организации производства, необходимое к достаточное для воспроизводства процесса
получения определенных продуктов, предметов, услуг, изменений или любых иных значимых результатов с заранее
заданными параметрами.
На основе данного определения можно выделить по меньшей мере три дополняющих друг друга группы технологий:
1) ресурсные (отличающиеся друг от друга тем, какие ресурсы используются для производства конкретного
продукта);
2) инструментальные (отличающиеся набором используемых орудий труда);
3) управленческие (отличающиеся способами организации производственного процесса).
В существующей литературе понятие «информационный менеджмент», как правило, связывается с двумя первыми
группами (типом ресурсов или типом инструментов). Куда более плодотворным представляется разговор об
информационном менеджменте как о технологии управленческой.
Надо исходить из предположения, что на современном этапе развития процессы модернизации во всех сферах
жизнедеятельности связаны скорее с организацией работы, чем с изменением характера используемых ресурсов или
обновлением инструментов. Компьютер, пришедший на смену картотечному ящику и пишущей машинке, — удобство и
не более того. Он не поменял природы гуманитарных занятий, так же как заменивший счеты калькулятор не произвел
революции в экономике. Происходящие у нас на глазах глобальные перемены связаны не с появлением баз данных и
персональных компьютеров, а с появлением новой среды коммуникации. Эта среда властно диктует особые формы
взаимоотношений, которые называются сетевыми. Сети как системы человеческого взаимодействия были известны
задолго до компьютерной эры, но благодаря новым техническим средствам они стали явлением. Описывать сетевые
отношения и рефлексировать по их поводу мы начали только с появлением Internet.
Сегодня есть все основания рассматривать информационные технологии как неотъемлемый компонент технологий
управленческих. Практически все вновь формирующиеся структуры координации человеческой деятельности,
например, офисные системы, строятся на основе новейших телекоммуникационных систем и оснащенных
современными компьютерами ресурсных центров. Да и вполне традиционный управленец не мыслит сегодня своей
работы без компьютера на столе. Можно дать длинный перечень элементов новых управленческих технологий,
проникающих и в культурную сферу благодаря сети Internet. Среди этих элементов:
• средства оперативной коммуникации (электронная почта, списки рассылки, новостные разделы музейных сайтов);
• распределенные ресурсы и средства доступа к ним (базы данных, порталы, терминалы компьютерных сетей);
средства координации деятельности (электронные доски объявлений, форумы, электронные опросы);
• формы обратной связи и организации сотрудничества (гостевые книги, телеконференции);
•
наконец,
средства
производства
(инструментарий
поиска
ресурсов
и
партнеров,
стандартные
и
специализированные программные средства).
Но дело не только и не столько в этом. Техническая модернизация сама по себе не приводит к сдвигам в сознании.
Требуется еще некий фактор, который можно обозначить как переход от социального к медиа - пространству. Именно
сюда, в виртуальную среду, все более перемещаются места делового общения, обмена идеями и взаимного
консультирования (Web-клубы, Internet-кафе), средства совместного проектирования и продвижения проектов (Webлаборатории, обмен баннерами). Возникают целые виртуальные «поселения» с проблемно-ориентированной социальной
структурой и специализированными вспомогательными службами (Geocities, Fortunecity и др.). Информационные
технологии становятся неотъемлемой частью культуры.
Информационный менеджмент — совокупность методов и средств управления информацией и управление с
помощью информации деятельностью предприятия или организации.
Выделяют три вида информационного менеджмента: управление предприятием (организацией), внутренней
документацией и публикациями. Первый из видов включает вопросы организации источников информации, средств
передачи, создания баз данных, технологий обработки данных, обеспечение безопасности данных.
В круг задач менеджмента входят также разработка, внедрение эксплуатация и развитие автоматизированных
информационных систем и сетей, обеспечивающих деятельность предприятия (организации). В этих сетях должно быть
обеспечено управление информационными ресурсами. Важное значение имеют организации и обеспечение
взаимодействия с внешним информационным миром: сетями, базами данных, издательствами, типографиями и т.д.
Все возрастающая важность информационного менеджмента привела к появлению специалистов (информационных
менеджеров) занимающихся его задачами. Эти специалисты должны преобразовывать пассивную корпоративную
информацию в источники правдивых, так называемых рафинированных, сведений, определяющих успехи фирмы.
Информационный менеджмент превращается в базовую технологию организации управленческой деятельности во
всех сферах информационного общества.
Таким образом, создание информационного общества базируется на следующих утверждениях.
1. Переход к информационному обществу в рамках конкретного государства возможен при условии создания
единого информационного пространства на его территории.
2. Базовой составляющей единого информационного пространства являются информационные ресурсы, которые
создаются в процессе функционирования автоматизированных информационных систем всех сфер жизнедеятельности
государства (органов власти и управления, органов местного самоуправления, юридических и физических лиц).
Единое информационное пространство — это:
• интеграция информационных ресурсов различных сфер жизнедеятельности общества;
• обеспечение полноты, точности, достоверности и своевременности предоставления информации органам власти и
управления всех уровней, юридическим и физическим лицам;
• создание необходимых условий по информационному общению субъектов управления, хозяйствования и граждан;
•
предоставление возможности взаимодействия с информационными ресурсами других государств и
международных организаций.
3. Технологии открытых систем решают проблему создания единого информационного пространства как в рамках
одной страны, так и во всем мире.
4. Для перехода на технологии создания открытых информационных систем любое государство должно иметь
правительственные профили (профили государственного значения) для создания открытых информационных систем.
5. Открытые автоматизированные информационные системы являются сегодня базой для продуктивной работы
менеджера любого уровня и во всех предметных областях.
В общем случае структура информационного общества как целевое направление информационного менеджмента
представлена на рис. 1.2.
Рис. 1.2. Структура информационного общества как целевое направление информационного менеджмента
Тема 2.
Системное администрирование
Средства управления компьютером
В Windows 2000 был кардинально изменен интерфейс управления операционной
системой. В соответствии с новой концепцией Microsoft из системы Windows NT были
удалены все автономные и несовместимые друг с другом административные утилиты и
разработана единая среда управления, получившая название консоль управления Microsoft
(Microsoft Management Console, MMC). Эта общая консоль управления разработана для
запуска всех программных модулей администрирования, конфигурирования или
мониторинга локальных компьютеров и сети в целом. Такие законченные модули
называются оснастками (snap-ins). Консоль управления сама по себе не выполняет
никаких функций администрирования, но служит в качестве рабочей среды для запуска
оснасток, создаваемых как компанией Microsoft, так и независимыми поставщиками
программного обеспечения (Independent Software Vendor, ISV).
Появление ММС обусловлено желанием создать единую среду управления для
администрирования операционных систем Windows. Оснастки представляют собой
управляющие компоненты, которые объединены в среде ММС. Из нескольких оснасток
можно создать индивидуальный управляющий инструмент.
Консоль ММС включает в себя интерфейсы прикладного программирования (API),
оболочку пользовательского интерфейса (консоли) и набор инструкций.
Microsoft Management Console позволяет создавать более совершенные
административные инструменты, которые могут предоставлять различные уровни
функциональных возможностей. Эти инструменты можно легко интегрировать в
операционную систему, а также изменять и настраивать по своему усмотрению. В данном
случае инструмент представляет собой не просто одиночное приложение. Инструмент
может состоять из одной или нескольких оснасток, и каждая оснастка, в свою очередь,
может содержать дополнительные оснастки расширения. Такая модульная структура
позволяет системному администратору существенно снизить стоимость управления
системой благодаря возможности создания индивидуальных инструментов на основе
выбранных оснасток, которые предоставляют только необходимые возможности и
средства просмотра. Администратор может затем сохранять каждый индивидуальный
инструмент в отдельном файле (файле консоли ММС с расширением msc) и отправлять
его другим пользователям или администраторам, которым делегированы права на
выполнение данных административных задач.
ММС и модель администрирования Windows 2000 представляют собой следующий
шаг в развитии технологий администрирования. Консоль управления имеет ряд
преимуществ, которые заключаются в упрощении интерфейса, предоставлении больших
возможностей
по
настройке
разработанных
решений
для
определенных
административных проблем и в обеспечении различных уровней функциональности. В
большинстве случаев достаточно сложно разработать инструмент, который будет являться
неотъемлемой частью операционной системы. С помощью ММС эта задача существенно
упрощается. Тщательно разработанный административный инструмент идеально
подойдет для решения стоящих перед вами задач и будет иметь интуитивно понятный
интерфейс. Такой инструмент также будет использовать возможности уже имеющихся
инструментов, что снимает необходимость "изобретать велосипед".
В операционные системы Windows 2000 и следующие версии продуктов семейства
BackOffice® оснастки ММС включены в качестве стандартных административных
программ.
Microsoft Management Console представляет собой приложение с многооконным
интерфейсом, которое активно использует технологии Интернет. Компания Microsoft и
независимые поставщики программного обеспечения могут разрабатывать оснастки ММС
для выполнения задач управления локальным компьютером и сетью в целом.
ММС не подменяет собой имеющиеся инструменты управления предприятиями,
такие как HP OpenView или IBM Tivoli Management Environment. Консоль управления
расширяет возможности данных инструментов, предоставляя им возможность
взаимодействия друг с другом или объединяя эти инструменты в оснастки, доступ к
которым может осуществляться из ММС. Например, приложение управления
предприятием может обнаружить событие и отправить извещение в оснастку (рис. 2.1).
Системный администратор затем обнаружит событие в сеансе ММС и предпримет
необходимые меры.
Интерфейсы программирования ММС позволяют интегрировать оснастки с
консолью (рис. 2.2). Данные интерфейсы предоставляют только расширения
пользовательского интерфейса, поскольку каждая оснастка самостоятельно определяет
механизм выполнения своих задач. Интерфейсы ММС позволяют оснасткам совместно
использовать общую хост-среду и обеспечивают интеграцию между приложениями.
Консоль ММС не выполняет никаких функций управления.
Рис. 2.1. ММС обеспечивает общий интерфейс для инструментов управления,
включая приложения управления предприятием
Рис. 2.2. Прикладные интерфейсы позволяют интегрировать оснастки с консолью
Компания Microsoft и независимые поставщики программного обеспечения могут
разрабатывать инструменты управления для запуска в среде ММС и приложения,
которыми будут управлять инструменты ММС.
Инструменты, не предназначенные для работы в среде ММС, могут быть
интегрированы в ММС посредством оснасток или запущены независимо. Системный
администратор может одновременно запускать не-ММС инструменты управления и
экземпляры ММС на одном компьютере.
Преимущества ММС:
1. Возможность индивидуальной настройки и передача полномочий. Помимо
обеспечения интеграции и общей среды для административных инструментов,
консоль ММС предоставляет возможность полностью индивидуальной
настройки, так что администраторы могут создавать такие консоли управления,
которые будут включать только необходимые им инструменты Такая настройка
позволяет ориентировать администрирование на выполнение конкретных задач,
причем администратор может выделить только необходимые объекты и
элементы. Настройка консоли также позволяет администраторам передавать
определенную часть полномочий менее опытным сотрудникам. С помощью
ММС можно создать консоль, которая будет содержать объекты, необходимые
для выполнения только определенных функций.
2. Интеграция и унификация. ММС обеспечивает общую среду, в которой могут
запускаться оснастки, и администраторы могут управлять различными
сетевыми продуктами, используя единый интерфейс, что упрощает изучение
работы с различными инструментами.
3. Гибкость в выборе инструментов и продуктов
В среде ММС можно использовать различные инструменты и оснастки. Для
использования в среде ММС оснастка должна поддерживать объектную модель
компонентов (Component Object Model, COM) или распределенную COM (Distributed
Component Object Model, DCOM) Это позволяет выбирать наиболее оптимальный продукт
среди оснасток, причем гарантируется его полная совместимость со средой ММС.
Пользовательский интерфейс ММС
Консоль управления ММС имеет пользовательский интерфейс, позволяющий
открывать множество документов (Multiple Document Interface, MDI) Интерфейс консоли
ММС на примере оснастки Computer Management показан на рис. 2.3.
Родительское окно ММС имеет главное меню и панель инструментов Главное
меню обеспечивает функции управления файлами и окнами, а также доступ к справочной
системе.
Дочерние окна ММС представляют собой различные средства просмотра
автономного документа консоли. Каждое из этих дочерних окон содержит панель
управления, панель структуры (scope pane) и панель результатов, или сведений (result
pane) Панель управления содержит меню и набор инструментов. Панель структуры
отображает пространство имен инструментов в виде дерева, которое содержит все
видимые узлы, являющиеся управляемым объектом, задачей или средством просмотра
Панель результатов в дочернем окне отображает список элементов выбранного
узла. Данный список может содержать папки, оснастки, элементы управления, вебстраницы, панели задач (taskpad) и другие элементы
Средства ММС также позволяют отображать окно в упрощенном виде, доступном
для менее опытных администраторов. В наиболее простой форме окно может содержать
набор значков, которые обеспечивают доступ к определенным задачам.
Рис. 2.3. Окно оснастки Управление компьютером (Computer Management)
Архитектура ММС
На рис. 4 представлена архитектура ММС. Диспетчер оснасток (Snap-m Manager)
дает системному администратору или разработчику оснасток возможность добавлять,
удалять или изменять оснастки. Кроме того, Диспетчер оснасток позволяет системному
администратору определить, является ли некоторая оснастка изолированной или зависит
от других оснасток
Диспетчер оснасток сохраняет произведенные установки в виде инструмента или
документа (файл с расширением msc) Пользователь определенного инструмента
взаимодействует с элементами, которые находятся в верхней части рисунка (файл *.msc и
элементы пользовательского интерфейса) Разработчики и администраторы работают с
элементами, показанными в нижней части рис. 2.4 (Диспетчер оснасток и оснастки
Просмотр событий и Маршрутизация и удаленный доступ)
При загрузке документа ММС инициализируется одна или несколько оснасток, как
показано на рис. 2.5.
Данные оснастки объединены для создания пространства имен — набора узлов,
которые отображаются в виде дерева на панели структуры. Пространство имен является
главным деревом, которое показывает возможности инструмента. Пространство имен
может включать все управляемые объекты сети — компьютеры, пользователей, группы и
т.д. Пространство имен содержит объекты, средства просмотра и задачи. Дочерние окна
ММС представляют собой средства просмотра главного пространства имен.
Рис. 2.4. Модель ММС — инструмент консоли (файл *.msc взаимодействует с
диспетчером оснасток для извлечения оснасток и представления элементов
пользовательского интерфейса)
Рис. 2.5. Когда пользователь открывает файл ММС, загружаются оснастки и
генерируется пользовательский интерфейс
Оснастки и работа с ними
Все инструменты ММС состоят из совокупности оснасток. Каждая оснастка
представляет собой минимальную единицу управления. С технической стороны оснастка
представляет собой "OLE-сервер внутри процесса" (in-proc server — так часто называют
DLL-библиотеки в модели СОМ), который выполняется в контексте процесса ММС.
Оснастка может вызывать другие элементы управления и динамические библиотеки
(DLL) для выполнения своей задачи.
Ряд оснасток могут быть объединены администратором в инструмент (также
называется документом), который сохраняется в файле с расширением msc (Management
Saved Console). Администратор использует инструменты для управления сетью. Файл
*.msc можно затем передать другому администратору (например, по электронной почте),
который сможет использовать содержащийся в нем инструмент на своем рабочем месте.
Благодаря возможности индивидуальной настройки ММС, администратор может
создать идеальный инструмент на основе доступных оснасток. Кроме того, инструмент
ММС, включающий в себя, например, стандартные оснастки, занимает в памяти меньше
места, чем эти оснастки, запущенные по отдельности.
В ММС поддерживаются два типа оснасток:
1. Изолированная оснастка (stand-alone snap-in) обеспечивает выполнение своих
функций даже при отсутствии других оснасток, например, Управление
компьютером (Computer Management).
2. Оснастка расширения (extension snap-in) может работать только после
активизации родительской оснастки. Функция оснастки расширения
заключается в увеличении числа типов узлов, поддерживаемых родительской
оснасткой. Оснастка расширения является подчиненным элементом узлов
определенных типов, и при каждом запуске узлов данных типов консоль
автоматически запускает все связанные с ней расширения. В качестве примера
можно привести оснастку Диспетчер устройств (Device Manager).
Оснастки расширения могут предоставлять различные функциональные
возможности. Например, такие оснастки могут расширять пространство имен
консоли, увеличивать число пунктов в меню или добавлять определенные
мастера.
Инструмент (и одноименная оснастка) Управление компьютером (рис. 2.3)
является одним из основных средств системного администратора для конфигурирования
компьютера. Данную оснастку можно использовать для администрирования как
локальной системы, так и удаленных компьютеров (в том числе — с некоторыми
ограничениями — и компьютеров с Windows NT 4.0). Это позволяет администратору со
своего рабочего места устранять проблемы и конфигурировать любой компьютер в сети,
на котором установлена Windows 2000.
Узел Служебные программы отображает конфигурацию компьютера и
объединяет средства управления им. Сотрудники службы поддержки используют данную
информацию при устранении проблем на локальном компьютере.
Узел Просмотр событий соответствует оснастке с одноименным названием и
стандартной утилите, которая имеется в Windows NT 4.0. С ее помощью можно
просматривать журналы регистрации событий операционной системы, безопасности и
приложений.
Узел Сведения о системе содержит исчерпывающую информацию об аппаратном
обеспечении компьютера, системных компонентах и программной среде Системная
информация разделена на четыре категории, которым соответствуют узлы Сведения о
системе (System Summary), Ресурсы аппаратуры (Hardware Resources), Компоненты
(Components) и Программная среда (Software Environment) на панели структуры:
а) Узел Сведения о системе отображает общую информацию о
компьютере и операционной системе: версию ОС и номер сборки,
тип процессора, объем ОЗУ, версию BIOS, региональные
установки, а также информацию об объеме физической и
виртуальной памяти на компьютере.
б) Узел Ресурсы аппаратуры отображает информацию об
аппаратных установках, таких как каналы DMA, номера
прерываний (IRQ), адреса ввода/вывода (I/O) и адреса памяти. Узел
Конфликты/Совместное использование (Conflicts/Sharing)
идентифицирует устройства, которые совместно используют
ресурсы или конфликтуют с другими ресурсами. Такая информация
помогает выявлять проблемы, возникающие с аппаратными
устройствами.
в) Узел Компоненты отображает информацию о конфигурации
Windows и используется для определения статуса драйверов
устройств, сетевых устройств и программного обеспечения
мультимедийных устройств. Кроме того, данный узел содержит
обширную информацию об истории драйверов с записью всех
изменений, которые производились с компонентами.
г) Узел Программная среда отображает "снимок" программного
обеспечения, загруженного в память компьютера. Данная
информация может быть использована для просмотра списка
выполняющихся задач или для выяснения номера версии продукта.
В узел Сведения о системе другими приложениями могут быть добавлены узлы с
целью отображения информации, характерной для данных приложений. Пример такого
узла — Internet Explorer 5.
Оснастка расширения Оповещения и журналы производительности позволяет
сконфигурировать журналы для записи данных и службу системных оповещений (Alerter)
для уведомления о превышении каким-либо счетчиком определенного значения. Данная
оснастка позволяет фиксировать данные о степени использования компьютера и работе
служб (сервисов) на локальных и удаленных компьютерах.
Оснастка Общие папки позволяет просматривать информацию о соединениях и
использовании ресурсов локального и удаленного компьютеров. Данная оснастка
используется вместо программы Server в Control Panel систем Windows NT 4.0.
С помощью оснастки можно выполнять следующие задачи:
д) Создавать, просматривать, изменять свойства и удалять общие
ресурсы на локальном или удаленном компьютерах (Windows NT
4.0 или Windows 2000) и устанавливать разрешения на доступ к
ним. Кроме того, можно управлять режимом кэширования общих
папок (в случае их использования в качестве изолированных папок).
е) Просматривать список удаленных пользователей, подключенных к
компьютеру, и отключать их.
ж) Просматривать список файлов, открытых удаленными
пользователями, и закрывать открытые файлы
Оснастка Общие папки содержит три узла: Ресурсы (Shares), Сеансы (Sessions) и
Открытые файлы (Open Files). При выборе данных узлов в панели результатов
отображается содержание соответствующего узла.
Узел Диспетчер устройств представляет одноименную оснастку, которая
отображает в виде дерева все аппаратные устройства, установленные на локальном
компьютере, и показывает их состояние, версии программных драйверов, используемые
ресурсы (порты ввода/вывода, адреса памяти и IRQ). Данная оснастка позволяет изменять
конфигурацию аппаратных элементов, а также механизм их взаимодействия с
центральным процессором компьютера Диспетчер устройств позволяет:
з) Выяснить, корректно ли работает аппаратное обеспечение
компьютера;
и) Изменить конфигурационные настройки оборудования;
к) Идентифицировать драйверы устройств, которые загружены для
каждого устройства, и получить информацию о драйверах всех
устройств;
л) Изменить дополнительные установки и параметры устройств П
Инсталлировать обновленные драйверы устройств;
м) Отключать и активизировать устройства;
н) Идентифицировать конфликты устройств и вручную
конфигурировать установки ресурсов;
о) Распечатать суммарную информацию об устройствах, которые
установлены на вашем компьютере
Оснастка Диспетчер устройств преимущественно используется для проверки
состояния аппаратного обеспечения и обновления драйверов устройств на компьютере.
Опытные пользователи, которые хорошо разбираются в аппаратном обеспечении
компьютера, могут при помощи диагностических возможностей Диспетчера устройств
устранять конфликты устройств и изменять установки ресурсов.
Для каждого устройства на компьютере выделяется уникальный набор системных
ресурсов для обеспечения корректной работы устройства. В число этих ресурсов входят:
п) Номера запросов на прерывание (Interrupt Request, IRQ);
р) Каналы прямого доступа к памяти (Direct Memory Access, DMA);
с) Адреса портов ввода/вывода (Input/Output, I/O);
т) Диапазоны адресов памяти.
Механизм Plug and Play системы Windows 2000 производит выделение данных
ресурсов автоматически в ходе установки всех устройств, которые поддерживают данный
механизм. Если два устройства обращаются к одним ресурсам, то возникает аппаратный
конфликт. В этом случае необходимо вручную изменить установки ресурсов для
обеспечения их уникальности для каждого устройства. В общем случае не следует
изменять установки ресурсов вручную, поскольку при этом могут возникать сложные
конфликтные ситуации, для устранения которых требуется глубокое понимание • работы
аппаратных и программных средств (в том числе — и драйверов).
Диспетчер устройств позволяет отключать и удалять устройства из системной
конфигурации компьютера. При отключении устройства физическое устройство остается
подключенным к компьютеру, но производятся соответствующие изменения в системном
реестре, так что драйверы устройства не будут загружены при следующем запуске
системы. Отключение устройств полезно, если необходимо иметь несколько аппаратных
конфигураций компьютера или если работа ведется на портативном компьютере,
используемом вместе со станцией расширения (док-станция, docking station).
Аппаратный профиль представляет собой набор инструкций, которые указывают
системе Windows 2000, какие устройства следует запустить при включении компьютера.
При инсталляции Windows 2000 создается аппаратный профиль по умолчанию. В данном
профиле активизируются все устройства, имеющиеся на компьютере к моменту
инсталляции операционной системы.
Аппаратные профили особенно полезны, если используется портативный
компьютер. Например, можно создать профиль, который будет активизировать сетевую
карту и внешний монитор, если компьютер подключен к станции расширения, и профиль
без поддержки данных устройств в противном случае.
Узел Локальные пользователи и группы соответствует одноименной оснастке,
аналогом которой в Windows NT Workstation 4.0 была административная утилита
Диспетчер пользователей (User Manager). Функции и назначение остались неизменными: с
помощью данной оснастки создаются, модифицируются и удаляются учетные записи
пользователей и групп на локальном компьютере.
Контейнер Запоминающие устройства содержит оснастки, которые используются
для управления и обслуживания логическими дисками и дисковыми накопителями:
у) Оснастка Управление дисками управляет логическими дисками.
ф)Оснастка Дефрагментация диска используется для анализа и
дефрагмен-тации удаленных и локальных логических дисков.
х) Оснастка Логические диски представляет собой инструмент
Windows Management Instrumentation (WMI), который позволяет
управлять удаленными или локальными логическими дисками. С
помощью оснастки можно:
o Просматривать свойства дисков, такие как тип диска, его
метку, тип файловой системы, объем используемого
пространства;
o Менять метки (имена) дисков;
o Изменять параметры безопасности для дисков :
разрешения на доступ, политику аудита и владельца диска;
ц) С помощью оснастки Съемные ЗУ можно легко управлять
библиотеками ленточных накопителей, сменными оптическими
дисками и устройствами с автоматической подачей дисков
(jukebox).
С помощью узла Службы и приложения можно, изменяя параметры, управлять
инсталлированными службами или серверными приложениями, например, Веб-сервером.
Узел Управляющий элемент WMI (и одноименная оснастка) позволяет
конфигурировать средства (инструменты) Windows Management Instrumentation (WMI) в
локальной системе и на удаленных компьютерах. Например, с помощью данной оснастки
можно задавать разрешения для проверенных (authorized) пользователей и групп,
сохранять репозитарий объектов WMI, включать и выключать регистрацию ошибок в
журналах.
Узел Службы (также доступен в виде отдельного инструмента с одноименным
названием) позволяет запускать, останавливать, приостанавливать и возобновлять работу
служб (сервисов) на удаленном и локальном компьютерах, а также конфигурировать
опции запуска и восстановления. Оснастка Службы заменяет утилиту (апплет) Службы
(Services) на панели управления предыдущих версий операционной системы.
С помощью оснастки Службы можно выполнять следующее:
ч) Управлять службами на локальном и удаленных компьютерах,
включая удаленные компьютеры под управлением Windows NT
4.0.;
ш) Определять операции по восстановлению, если служба (сервис)
работает неправильно (например, задавать перезапуск сервиса или
компьютера) (только на компьютерах с Windows 2000);
щ) Создавать индивидуальные имена и описания для сервисов,
чтобы их можно было легко идентифицировать (только на
компьютерах с Windows 2000).
Служба индексирования инсталлируется как стандартный компонент Windows
2000. Эта служба индексирует содержимое всех дисков локального компьютера, что
позволяет пользователю производить поиск любого слова или фразы, которые содержатся
в документах на данном компьютере. Оснастка Служба индексирования — это новый
инструмент с графической оболочкой для службы индексирования, который упрощает
выполнение ряда административных задач, включая следующие:
ы)Проверка состояния процесса индексации и параметров
индексируемых каталогов;
э) Установка глобальных параметров для всех каталогов на
компьютере;
ю) Создание и конфигурирование новых каталогов для обеспечения
оптимальной производительности;
я) Выбор индексируемых каталогов.
Тема 3.
Сетевое администрирование
В Windows 2000 имеются средства для подключения компьютера к Интернету,
локальной сети или к другим компьютерам, а также для использования сетевых ресурсов
и служб в локальной сети или удаленно.
Исходящие подключения (outgoing connections) устанавливают связь с сервером
удаленного доступа, используя определенный метод доступа (ЛВС, модем для
коммутируемых линий, адаптер и линия ISDN и т. п.) для подключения к сети. В отличие
от исходящего, входящее подключение (incoming connection) позволяет компьютеру под
управлением Windows 2000 поддерживать подключения, инициализируемые другими
компьютерами. Это означает, что этот компьютер может работать как сервер удаленного
доступа (remote access server). Вне зависимости от того, является ли связь локальной
(ЛВС) или удаленной (телефонная линия, ISDN и т. п.), подключения можно настроить
так, чтобы они могли полноценно выполнять все требуемые функции. Например, при
помощи любых сетевых подключений можно печатать на сетевых принтерах, получать
доступ к сетевым дискам и файлам, просматривать другие сети или получать доступ к
Интернету (если подключение поддерживает соответствующие протоколы).
Поскольку все службы и методы связи настраиваются внутри подключения, для
конфигурирования параметров подключения не нужно обращаться к внешним
инструментам управления. Например, параметры настройки для телефонного
подключения при помощи модема включают те, которые нужно использовать до, в
течение и после подключения: тип модема для связи; тип шифрования пароля,
необходимый для этого подключения; сетевые протоколы, применяемые после
установления соединения. Состояние каждого подключения (продолжительность и
быстродействие) можно просматривать непосредственно в окне подключения.
Защита на уровне локальной системы и защита на уровне доменов в Windows 2000,
применение хостов безопасности, шифрование данных, аутентикация и ответный вызов
обеспечивают безопасный доступ для подключений к сети и удаленного доступа к сети.
Существует пять типов сетевых подключений (табл. 3.1).
Таблица 3.1. Типы сетевых подключений
Тип подключения
Телефонное
подключение
Технология связи
Использование
Модем, ISDN, X.25
Соединение с корпоративной сетью или
(Dial-up
Интернетом с использованием телефонного
подключения
connection)
ЛВС
(LAN,
Local
Area connection)
Ethernet, Token Ring, кабельный модем,
Типичный корпоративный пользователь
xDSL, FDDI, IP no ATM, IrDA, радиомодем,
E1/T1 и т.п.
Виртуальная частная
сеть
(VPN
Виртуальные частные сети по протоколам
connection, РРТР
Virtual private network)
или
L2TP,
объединяющие
Безопасное соединение с корпоративной
или сетью через Интернет
подключающие к корпоративным сетям через
Интернет или другую сеть общего пользования
(public network)
Прямое подключение
(Direct Connection)
Последовательное
инфракрасная
связь,
соединение,
параллельный
карманного
или
кабель портативного компьютера с настольным
(DirectParallel)
Входящее
Соединение
Коммутируемая связь, VPN или прямое
компьютером
Подключение к удаленному компьютеру
подключение (Incoming подключение
или корпоративному серверу удаленного
connection)
доступа
Типы подключений
Локальное подключение
Как правило, в организациях компьютеры под управлением Windows 2000
подключены к локальной сети (ЛВС). При инсталляции операционная система
автоматически обнаруживает сетевой адаптер и создает локальное сетевое подключение
для данного адаптера. Это подключение отображается, как и все другие подключения, в
папке Сеть и удаленный доступ к сети. По умолчанию локальное подключение всегда
активно. Локальное подключение — единственный тип подключения, которое
автоматически становится активным после запуска компьютера или установки ОС.
Если разъединить локальное подключение, оно больше не активизируется
автоматически.
Для установления локальных подключений применяются среды Ethernet, Token
Ring, кабельные модемы, xDSL, FDDI, IP no ATM, IrDA (инфракрасная связь), радио- и
эмулированные ЛВС на базе ATM. Эмулированные локальные сети используют драйверы
виртуальных адаптеров, например, драйверы, поддерживающие протокол LANE (LAN
Emulation, эмуляция ЛВС).
Виртуальные частные сети (VPN)
Протоколы РРТР или L2TP, по умолчанию установленные на компьютере,
обеспечивают надежный доступ к ресурсам в сети, соединяясь с сервером удаленного
доступа Windows 2000 через Интернет или другую сеть. Если для создания сетевого
подключение к частной (private) сети используется общедоступная (public) сеть, то
совокупность таких подключений называется виртуальной частной сетью (Virtual
Private Network, VPN). Достоинства таких сетей перечислены в табл. 3.2.
Таблица 3.2. Достоинства использования сетей VPN
Преимущество
Пример
Меньшая стоимость
Для подключения используется Интернет (вместо установления прямого телефонного
подключения с использованием дорогой междугородной связи). Поскольку Интернетпровайдер сам поддерживает оборудование связи (модемы, адаптеры ISDN и т. п.), при
развертывании сети нужно закупать и сопровождать меньшее количество оборудования
Аутсорсинг
(Передача
лицам,
забот
Пользователь может по городскому номеру подключиться к телефонной компании или
третьим ISP, который затем подключит его к серверу удаленного доступа Windows 2000 и к
outsourcing) корпоративной сети. Телефонная компания или ISP управляет модемами и телефонными
по
поддержке линиями, выделенными для коммутируемого доступа. ISP поддерживает сложную
телефонных
инфраструктуру коммуникационного оборудования, а сетевой администратор корпорации
подключений
занимается централизованным управлением учетными записями пользователей на сервере
удаленного доступа
Расширенная
Подключение через Интернет (если используются протоколы PPTP/L2TP) является
безопасность
шифрованным и безопасным, поскольку сервер удаленного доступа поддерживает
современные протоколы аутентификации и шифрования. Конфиденциальные данные
надежно защищены от пользователей Интернета, но доступны для пользователей
виртуальной частной сети.
Поскольку данные, передаваемые по VPN-подключению зашифрованы, используемые
адреса защищены от просмотра извне; в сети Интернет "видны" только внешние IP-адреса
(концов соединения). Это особо важно для корпораций с внутренними IP-адресами,
поскольку исключаются административные затраты на изменение IP-адресов для
удаленного доступа через Интернет
Поддержка сетевых
протоколов
Поскольку поддерживаются широко распространенные сетевые протоколы (включая
TCP/IP, IPX и NetBEUI), с использованием VPN можно дистанционно выполнять любое
приложение, зависящее от конкретного сетевого протокола
Как показано в следующих примерах, есть два способа создать VPN -подключение:
устанавливая соединение с ISP, или соединяясь с Интернетом напрямую.
Пример 1. VPN-подключение сначала производит запрос к Интернет-провайдеру.
После того как это подключение произведено, VPN-подключение делает другой запрос к
серверу удаленного доступа, который устанавливав туннель L2TP или РРТР. После
аутентификации можно получать доступ корпоративной сети, как это показано на рис. 3.1.
Рис. 3.1. VPN-подключение на основе подключения к Интернет-провайдеру
Пример 2. Пользователь, имеющий выход в Интернет, соединяется с сервером
удаленного доступа при помощи VPN-подключения (рис. 3.2). Таким пользователем
может быть тот, чей компьютер подключен к локальной сети, пользователь кабельного
модема или абонент службы типа ASDL, где протокол IP доступен сразу после включения
компьютера. Драйвер РРТР или L2TP создает туннель через Интернет и производит
подключение к серверу удаленного доступа, использующему РРТР или L2TP. После
аутентификации пользователь может получить доступ к корпоративной сети, как и в
предыдущем примере.
РИС. 3.2. VPN-подключение, использующее существующее подключение к
Интернету
Меньшая стоимость. При помощи VPN мобильные пользователи и сотрудникинадомники (telecommuters) могут получить доступ к корпоративной локальной сети через
Интернет за меньшую плату, чем при традиционных решениях по поддержке удаленного
доступа.
Гораздо
эффективнее
использовать
мощную
коммуникационную
инфраструктуру телефонной компании, чем прокладывать собственную сеть,
устанавливать телефонные линии и закупать коммутаторы.
Подключение к виртуальной частной сети через сетевой адаптер подобно набору
номера при помощи модема для подключения к обычному серверу удаленного доступа.
VPN освобождает корпорацию от эксплуатационных расходов и затрат на покупку
модемных пулов и специально предназначенных для этого аналоговых телефонных
линий. Модемы и сопутствующая инфраструктура находятся в ведении поставщика услуг
Интернета, при этом не страдают ни безопасность, ни возможности управления
удаленным доступом. В то же время, очевидны преимущества безопасности доступа к
частным данным, обеспечиваемой дополнительной аутентификацией, шифрованием и
сжатием данных пользователя.
Аутсорсинг телефонных подключений. Коммуникационное оборудование,
необходимое для телефонных подключений, достаточно сложно. На большом
предприятии создание сервера удаленного доступа для поддержки телефонных
подключений на базе Windows 2000 требует установки модемов, контроллеров, а также
прокладки множества коммуникационных кабелей. Кроме того, большинство решений не
обеспечивает эффективную поддержку технологий ISDN, V.34 и V.90.
Корпорации часто выбирают аутсорсинг (outsourcing) коммутируемого доступа к
своим базовым корпоративным сетям при помощи рентабельного, не зависящего от
протокола, безопасного способа, который не требует никак изменений в существующем
адресном пространстве. Поддержка виртуальных глобальных сетей на основе VPNподключений — один из путей, при помощи которого Интернет-провайдер может
обеспечивать потребности корпораций. Таким образом, обслуживающая компания
поддерживает и управляет модемами удаленного доступа и каналами связи, оставляя
системному администратору корпорации управление пользователями и их
аутентификацию. В этом решении воплощены все преимущества аутентификации РРР,
шифрования и технологий сжатия (рис. 3.3).
Рис. 3.3. Пример сети, использующей аутсорсинг
В подключении не участвует драйвер РРТР; клиент просто устанавливает РРР подключение к серверу удаленного доступа или модемному пулу. В свою очередь, сервер
или пул модемов должен осуществить подключение с помощью РРТР для связи с
сервером удаленного доступа.
Улучшенная безопасность. VPN-подключения, использующие РРТР и L2TP
аутентифицируются по методам аутентификации протокола РРР на уровне пользователя,
включающим PAP, CHAP, SPAP, MS-CHAP и, дополнительно, ЕАР.
Благодаря возможностям протокола ЕАР (Extensible Authentication Protocol,
расширяемый протокол идентификации) и средств безопасности IP (IPSec), виртуальная
частная сеть предоставляет улучшенную безопасность для удаленных пользователей.
Пользуясь преимуществом аутентификации РРР параметрами шифрования, задавая РРТР фильтрацию на сервере удаленного доступа и ограничивая сервер удаленного доступа
работой только с аутентифицированными РРТР - клиентами, которые используют
шифрованные данные, системный администратор может укрепить безопасность данных и
управлять удаленными пользователями намного эффективнее.
В некоторых средах данные являются строго конфиденциальными и может
потребоваться, чтобы они были физически отделены и скрыты от большинства
корпоративных пользователей. Финансовые или личные данные — это данные,
требующие максимальной защищенности. Пользователи в корпоративной интрасети,
которым предоставлены соответствующие разрешения, могут устанавливать удаленное
VPN-соединение с VPN-сервером и получать доступ к защищенным ресурсам частной
сети отдельных подразделений корпорации. Весь обмен данными через VPN шифруется,
что обеспечивает конфиденциальность данных. Пользователи, не имеющие
соответствующих разрешений по установлению VPN-подключения с VPN-сервером, не
могут увидеть этот "скрытый" сервер.
Поддержка сетевых протоколов. Поскольку технология организации VPN
поддерживает наиболее распространенные сетевые протоколы, клиентам сетей Ethernet,
TCP/IP, IPX и NetBEUI не требуются дополнительные затраты на использование VPN.
Любой сетевой протокол, поддерживаемый службой удаленного доступа, поддерживается
и в технологии VPN. Это означает, что можно удаленно выполнять приложения,
зависящие от определенных сетевых протоколов. В свою очередь, это снижает затраты по
созданию и поддержке VPN-подключений.
Безопасность IP-адресов. Если в корпоративной сети используется
незарегистрированный IP-адрес, то можно направлять трафик через Интернет, указывая
только один реальный внешний IP-адрес. Внутри VPN-пакета содержится как этот
реальный адрес, так и частный адрес получателя. Поскольку пакет зашифрован, адреса
абонентов удаленной частной сети защищены от просмотра. В Интернете видны только
внешние IP-адреса. Преимущество VPN наиболее очевидно для корпораций с частными
внутренними IP-адресами, поскольку им не требуются административные затраты на
изменение IP-адресов для организации удаленного доступа.
Администрирование VPN. При помощи Active Directory (на Windows 2000 Server)
администратор системы может настраивать VPN для пользователя, значительно усиливая
безопасность сети, например, задавать уровни шифрования данных и паролей, а также
аутентификацию. Эти требования могут применяться к индивидуальным пользователям
или к группе однотипных пользователей (при помощи групповой политики). Например,
администратор системы может настроить удаленный доступ, задав такую групповую
политику, чтобы для всех пользователей группы, которой она назначена, требовалась
аутентификация с использованием протокола ЕАР и сильное шифрование данных (128битное). При наличии групповой политики критерии безопасности автоматически
устанавливаются по отношению к любому пользователю, которому назначена эта
групповая политика, когда он соединяется с сервером удаленного доступа.
Телефонные (коммутируемые) подключения
Телефонное (коммутируемое) подключение (dial-up connection) соединяет
компьютер с корпоративной сетью или с Интернетом при помощи устройств,
подключаемых к коммутируемой телефонной сети. Такими устройствами могут быть:
модем (стандартная телефонная линия), платы ISDN (линии ISDN) или оборудование для
подключения к сети Х.25 по соответствующему каналу.
Обычно у пользователя имеется одно или два модемных подключения, например, с
Интернетом и со своей корпоративной сетью. Windows 2000 позволяет создавать
несколько телефонных коммутируемых подключений, чтобы осуществить более сложную
схему подключений.
Наиболее часто телефонное включение производится с помощью модемов и
стандартных аналоговых телефонных линий, которые есть везде и удовлетворяют
большинству требований мобильного пользователя. Стандартные аналоговые телефонные
линии также называются PSTN (Public Switched Telephone Network, коммутируемая
телефонная сеть общего пользования) или POTS (Plain Old Telephone Service, простая
старая телефонная служба).
Прямые подключения
Windows 2000 позволяет создавать физическое соединение с другим компьютером
через последовательный кабель, кабель прямого параллельного подключения
(DirectParallel), модем, устройство ISDN или другим способом. Например, можно
объединить две (или больше) физически не связанные сети, находящиеся в одном здании.
Если требуется доступ к ресурсам обеих сетей с одного компьютера, можно
использовать последовательное подключение по нуль-модемному кабели RS-232C
(кабель длиной до 15 м). Подключив кабель RS-232C к СОМ-портам компьютера и
сервера удаленного доступа, можно предоставить доступ к сети.
Драйвер прямого параллельного порта поддерживает подключения "компьютеркомпьютер", используя стандартные и расширенные параллельные порты, соединенные
параллельными кабелями разного типа.
Входящие подключения
При наличии входящего подключения компьютер под управлением Window- 2000
может служить сервером удаленного доступа. Можно создавать входящие подключения
для приема вызовов посредством: телефонного подключения (модем, ISDN, X.25),
виртуальной частной сети (РРТР, L2TP) или прямого подключения (последовательный,
параллельный кабель, инфракрасная связь). Для Windows 2000 Professional входящее
подключение может принимать до трех входящих вызовов для каждого из указанных
типов средств. На Windows 2000 Server число входящих вызовов ограничено только
возможностями компьютера (его аппаратным обеспечением).
При создании подключения определяются пользователи, которые могут
соединяться с данным входящим подключением, и сетевые протоколы, по которым они
могут работать. Для каждого пользователя, подключающегося к входящему
подключению, должна существовать локальная учетная запись
Клиенты входящих подключений. С Windows 2000 через входящее подключение
могут соединяться клиенты следующих операционных систем (помимо клиентов Windows
2000):







Клиенты Windows NT 4.0 — могут использовать все возможности входящего подключения, кроме
динамического распределения многоканального соединения, расширяемого протокола аутентификации
(ЕАР), клиента защиты передаваемых данных IPSec, а также L2TP для туннелированния через глобальные
сети.
Клиенты Windows NT 3.1, 3.5 и 3.51 — могут использовать те же возможности входящего подключения,
что и клиенты Windows NT 4.0, кроме многоканальных функциональных возможностей. Клиент Windows
NT 3.1 не поддерживает протокол двухточечного соединения (РРР), введенный в Windows NT 3.5.
Клиенты Windows 98— могут использовать все возможности входящего подключения, кроме
динамического распределения многоканального подключения и расширяемого протокола аутентификации
(ЕАР).
Клиенты Windows 95 — могут использовать все возможности входящего подключения, кроме
многоканального соединения, динамического распределения многоканального соединения и
расширяемого протокола аутентификации (ЕАР).
Клиенты Macintosh — могут соединяться с Windows 2000 и обращаться к файловым томам и принтерам
(только на Windows 2000 Server с соответствующими службами!), используя протокол удаленного доступа
AppleTalk (ARAP). Поддерживаются клиенты удаленного доступа AppleTalk 1.0, 2.х и 3.х.
Клиенты Windows for Workgroups, MS-DOS u LAN Manager — Windows N 4.0 Server поставлялся с
клиентами Microsoft Network Client for MS-DOS и TCP/IP-32 for Windows for Workgroups, которые
поддерживают удаленный доступ. (В поставку Windows 2000 Server клиенты для других платформ не
входят.) Поставляемые самостоятельно продукты Windows for Workgroups и LAN Manager также могут
работать с входящим подключением. Чтобы использовать полную систему переадресации, необходимо
установить Microsoft Network Client for MS-DOS (настройка по умолчанию). Если используется базовая
(basic) система переадресации, удаленный доступ не сможет использовать программу rasphone, а входящее
подключение не сможет быть установлено. Компьютеры под управлением Windows for Workgroups, MS
DOS и LAN Manager могут, используя удаленный доступ, обращаться через шлюз NetBIOS к серверам
NetBIOS, использующим TCP/IP, IPX или NetBEUI, но не могут выполнять приложения, использующие
TCP/IP или IPX на клиентской стороне. Эти клиенты также не поддерживают протокол РРР, введенный в
Windows NT 3.5.
Клиенты РРР. Клиенты РРР под управлением ОС сторонних поставщиков, использующие TCP/IP, IPX,
NetBEUI или ARAP, могут устанавливать входящее подключение. Входящее подключение автоматически
аутентифицирует клиентов РРР; специальные настройки РРР для таких клиентов не требуются.
Безопасность
Для телефонных и VPN-подключений можно задавать различные методы
аутентификации и уровни шифрования данных: в простейшем случае используются
незашифрованные имена и пароли, в более сложных — специальные протоколы
аутентификации (например, протокол ЕАР). ЕАР обеспечивает гибкую поддержку
широкого диапазона методов аутентификации, включая такие механизмы, как жетонная
карта (token card), одноразовый пароль и открытый ключ. Можно устанавливать
шифрование данных в подключении в зависимости от выбранного уровня
аутентификации пароля (MS CНАР или ЕАР). Наконец, можно настраивать параметры
ответного вызова повышения безопасности коммутируемого подключения.
Сетевые коммуникации
Сетевые протоколы, методы доступа и серверные протоколы обеспечивают
взаимодействие между компьютером и сетью.
Независимо от того, передается ли информация от компьютера к серверу по
прямому последовательному кабелю или по безопасному VPN-подключению через
поставщика услуг Интернета к корпоративной сети, для передачи информации
используются различные комбинации методов доступа и протоколы (табл. 3.3).
Таблица 3.3. Используемые протоколы и методы доступа
Сетевые
транспортные
TCP/IP, IPX/SPX, NetBEUI, AppleTalk
протоколы
Методы доступа
Телефонные линии и модемы, ISDN, X.25, последовательный кабель (RS232C), параллельный кабель (DirectParallel)
Серверные протоколы
РРР, SLIP, РРТР, L2TP, ARAP, АТСР
TCP/IP
Протокол управления передачей/Протокол Интернета (Transmission Control
Protocol/Internet Protocol, TCP/IP) — наиболее популярный протокол, который является
основой сети Интернет. Его возможности маршрутизации трафика обеспечивают
максимальную гибкость в сетях в масштабе предприятия.
В сетях на базе TCP/IP необходимо выделять IP-адреса клиентам. Клиентам также
может потребоваться наличие службы имен или другого метода разрешения имен (файлы
HOSTS, LMHOSTS).
Назначение IP-адресов подключению. В Windows 2000 каждому удаленному
компьютеру, подключающемуся к серверу удаленного доступа, который использует
TCP/IP, выделяется IP-адрес. IP-адрес автоматически предоставляется службой DHCP или
выбирается из статического диапазона, назначенного серверу удаленного доступа.
Если используется IP-адрес, заданный в конфигурации для данного телефонного
подключения сервер удаленного доступа Windows 2000 должен быть настроен так, чтобы
пользователям было разрешено запрашивать предопределенный адрес.
Разрешение имен для подключения. В дополнение к требованию выделения IPадреса, сетевому или телефонному подключению в сети на основе TCP/IP может
потребоваться механизм разрешения имен компьютеров в IP-адреса. В сети на базе
Windows 2000 можно использовать четыре способа разрешения имен:
 службу доменных имен (Domain Name System, DNS);
 службу Интернет-имен Windows (Windows Internet Name System, WINS)$
 широковещательное разрешение имен;
 разрешение имен с помощью файлов HOSTS и LMHOSTS.
Можно назначать подключению к сети и подключениям удаленного доступа к сети
те же серверы имен WINS и DNS, которые назначены серверу удаленного доступа.
В малых сетях, где IP-адреса не изменяются, подключения к сети и подключения
удаленного доступа к сети могут использовать файлы HOSTS или LMHOSTS для
разрешения имен. Поскольку эти файлы размещены на локальном диске, не требуется
передавать запрос на разрешение имен серверу WINS или серверу DNS и ждать ответ на
этот запрос через телефонное подключение.
Утилиты Интернета. В состав утилит TCP/IP в Windows 2000 входят программы
Ftp и Telnet. Ftp — консольная утилита, позволяющая устанавливать соединение с FTPсерверами и передавать файлы. Утилита Telnet — графическое приложение, позволяющее
входить на отдаленные компьютеры и выполнять команды так, будто они введены с
клавиатуры удаленного компьютера.
Сюда же относится ряд диагностических утилит, например Ping, Tracert и PathPing.
Эти утилиты позволяют проверять доступность удаленных компьютеров и
диагностировать соединение. Утилита Ping — консольная программа, позволяющая по
заданному имени или адресу определить время задержки передачи до указанного
компьютера. Утилита Tracert диагностирует последовательность межсетевых соединений
(хопов, hop) на пути между двумя компьютерами. Она показывает все маршрутизаторы на
пути сигнала и указывает время задержки до каждого из них. Утилита PathPing вмещает в
себя средства двух упомянутых утилит и имеет дополнительные возможности.
IPX/SPX
Iternetwork Packet Exchange/Sequenced Packet Exchange (Протокол обмена
кетами/Последовательный обмен пакетами, IPX/SPX) — протокол, изначально
предназначенный для сетей на базе Novell NetWare.
В среде Windows компьютер должен использовать (помимо протокола IPX/SPX)
редиректор (redirector) для NetWare, чтобы получить доступ к ресурсам Novell NetWare.
На компьютерах под управлением Windows 2000 Professional этот редиректор называется
Клиент для сетей NetWare (Client Service for NetWare, CSNW).
Сервер удаленного доступа в Windows 2000 является и маршрутизатором IPX/SPX,
и агентом SAP (Service Advertising Protocol, протокол объявления служб) (только для
клиентов удаленного доступа к сети). Серверы удаленного доступа и клиенты удаленного
доступа к сети используют протокол IPХСР (IPX Control Protocol, протокол конфигурации
IPX для РРР) в соответствии с RFC 1552 для настройки линии удаленного доступа на
использование IPX/SPX. После того как сервер удаленного доступа настроен, он
обеспечивает поддержку служб обмена файлами и печати и позволяет использовать
приложения Windows Sockets no IPX/SPX в сети NetWare совместно с подключениями к
сети и удаленным доступом к сети.
Адресация IPX для удаленных клиентов. Клиентам сетевых и коммутируемых
соединений адрес IPX всегда выдается сервером удаленного доступа. Номер сети IPX
генерируется автоматически сервером удаленного доступа, либо серверу удаленного
доступа задается статический пул сетевых номеров для назначения сетевым и
коммутируемым соединениям.
Для автоматически сгенерированных номеров сети IPX сервер удаленного доступа
под управлением Windows 2000 использует протокол RIP (Routing Information Protocol,
Информационный протокол маршрутизации) для IPX NetWare, чтобы определить номер
сети IPX, который не используется в сети IPX. Сервер удаленного доступа назначает этот
номер соединению.
NetBEUI
Расширенный интерфейс пользователя для NetBIOS (NetBIOS Extended User
Interface, NetBEUI) подходит для использования в малых рабочих группах или
несегментированных локальных сетях. Можно устанавливать шлюз NetBIOS (NetBIOS
gateway) и клиентский протокол NetBEUI на всех серверах удаленного доступа Windows
2000 и на большинстве сетевых клиентов Windows. Клиенты удаленного доступа Windows
NT/2000, LAN Manager. MS-DOS и Windows for Workgroups могут использовать NetBEUI.
AppleTalk
Работа с сетью в Apple Macintosh основана на протоколе AppleTalk. Приложения и
процессы могут взаимодействовать при помощи одиночной сети AppleTalk или
совокупности связанных AppleTalk сетей (ApplTalk internet) Используя AppleTalk,
приложения и процессы могут передавать данные и обмениваться информацией, а также
совместно использовать ресурсы, например принтеры и файловые серверы. Удаленный
доступ AppleTalk поддерживается в соответствии с AppleTalk Remote Access Protocol
(Протокол удаленного доступа AppleTalk, ARAP) и AppleTalk Control Protocol (Протокол
управления AppleTalk, ATCP).
Доступ через ISDN
Для повышения быстродействия сетевого подключения можно использовать
линию ISDN (Integrated Services Digital Network) — цифровую сеть с интегрированными
службами. Стандартные телефонные линии обычно позволяют осуществлять обмен со
скоростями до 56 Кбит/с, по линии ISDN можно достичь скоростей 64 и даже 128 Кбит/с.
Линия ISDN должна быть установлена телефонной компанией как на сервере, так и
на противоположном конце соединения. Работа ISDN также требует, чтобы на обоих
концах были установлены платы ISDN. Затраты на оборудование и линии ISDN могут
быть выше, чем на установку стандартных модемов и прокладку телефонных линий.
Однако быстродействие связи уменьшает время соединения, что сокращает денежные
затраты.
Линия ISDN состоит из двух В-каналов, передающих данные со скоростью 64
Кбит/с, и одного D-канала для передачи управляющих сигналов со скоростью 16 Кбит/с.
Можно конфигурировать каждый канал В, чтобы он работал как отдельный порт. При
помощи некоторых драйверов ISDN- устройств можно объединять каналы. Это означает,
что можно получить большую ширину полосы пропускания, настроив работу обоих Вканалов в качестве единственного порта. При конфигурации такого рода скорость линии
увеличивается до 128 Кбит/с.
Функция многоканальной связи (multilink) в Windows 2000 логически объединяет
части канала ISDN. Многоканальная связь объединяет несколько физических линий в
логическую совокупность (пучок, bundle) с увеличенной шириной полосы пропускания.
Кроме того, можно распределять многоканальную связь динамически, используя линии
только тогда, когда они реально требуются. Эта функция устраняет избыточность ширины
полосы пропускания, представляя существенное преимущество для пользователей.
SLIP
Протокол последовательной линии (Serial Line Internet Protocol, SLIP) — старый
стандарт удаленного доступа, ранее использовавшийся серверами удаленного доступа
UNIX. Подключения к сети и удаленный доступ к сети Windows 2000 поддерживают SLIP
и могут соединяться с любым сервером удаленного доступа по стандарту SLIP. Это
позволяет клиентам Windows 2000 соединяться с большим количеством серверов UNIX.
Подключения Х.25
Сеть Х.25 передает данные, используя протокол коммутации пакетов; при этом
данные передаются не по обычным зашумленным телефонным линиям, а по специальной
глобальной сети коммутации пакетов.
Подключения к сети и удаленный доступ к сети поддерживают Х.25, используя
сборщик/разборщик пакетов (Packet Assembler/Disassembler, PAD) и смарт-карты Х.25.
Можно также использовать модем и специальный коммутируемый доступ к Х.25
(например, Sprintnet или Infonet) вместо PAD или смарт-карты Х.25.
Для установления соединения клиент удаленного доступа Windows 2000 может
использовать смарт-карту Х.25 или производить телефонное подключение к Х.25 PAD.
Чтобы принимать входящие подключения с использованием Х.25 на компьютере под
управлением Windows 2000, необходимо использовать смарт-карту Х.25.
Протокол РРР
Протокол "точка-точка" (РРР) — набор стандартных протоколов, обеспечивающих
взаимодействие программного обеспечения удаленного доступа от различных
поставщиков. При помощи подключения с поддержкой РРР можно производить
подключения к удаленным сетям через любой сервер РРР, поддерживающий этот
промышленный стандарт. РРР также позволяет компьютеру, на котором функционирует
служба удаленного доступа Windows 2000, принимать запросы и обеспечивать доступ к
сети клиентам с программным обеспечением удаленного доступа третьих фирм,
соответствующим стандартам РРР.
Стандарты РРР также открывают дополнительные возможности, недоступные при
более старых стандартах, например SLIP. РРР поддерживает несколько методов
аутентификации, сжатие и шифрование данных. Большинство реализаций РРР позволяет
полностью автоматизировать последовательность входа в систему.
РРР также поддерживает несколько сетевых протоколов, в качестве которых могут
выступать TCP/IP, IPX или NetBEUI.
РРР — основа для протоколов РРТР и L2TP, которые используются в VPNсоединениях. РРР — эталон для большинства приложений удаленного доступа.
Подключение к Интернету
Доступ к Интернету легко реализуется при помощи сетевых подключений. Для
этого требуется выполнение следующих условий:
 Наличие протокола TCP/IP.
 Если пользователь принадлежит домену, то учетная запись пользователя
должна иметь разрешения удаленного доступа.
 Наличие модема или другого соединения с Интернет-провайдером.
 Наличие учетной записи у Интернет-провайдера.
Подлючение к Интернету производится путем установления прямого
подсоединения к Интернет-провайдеру и регистрации в его системе.
Подключение к Интернет-провайдеру может использовать модем и телефонную
линию, адаптер ISDN и линию ISDN, протокол удаленного доступа AppleTalk (ARAP),
протокол управления AppleTalk (АТСР), сеть Х.25, протокол туннелирования "точкаточка" (РРТР) или протокол туннелирования второго уровня (L2TP).
По модему желательно использовать самое надежное (устойчивое) и, по
возможности, самое быстрое соединение, что снизит время загрузки данных из Интернета.
Рекомендуется использовать модем со скоростью 28,8 Кбит/с или выше, имеющий также
поддержку протоколов V.34, V.90 и т. п.
Совместное использование Интернет-подключения
Возможность совместного использования Интернет-подключения
(Intenet
Connection Sharing, ICS) позволяет настроить Windows 2000 для подключения малой
офисной сети к Интернету. Например, можно создать сеть, которая соединяется с
Интернетом с помощью телефонного соединения. Если разрешить совместное
использование подключения на компьютере, соединенном по телефонной линии, то этот
компьютер предоставит службы преобразования сетевых адресов (Network Address
Translation, NAT), выдачи адресов (DHCP) и разрешения имен (DNS) всем компьютерам
домашней сети.
Можно настраивать приложения и службы, которые должны работать через
Интернет. Например, если пользователи сети хотят получить доступ к ресурсам SQL
Server корпоративной сети, можно настроить приложение SQL Server для подключения,
которому разрешено совместное использование. Услуги, предоставляемые сетью, можно
настроить так, чтобы к ним могли получить доступ пользователи Интернета.
Возможность совместного использования удобна в малом офисе, где
конфигурирование сети и подключение к Интернету выполняет компьютер под
управлением Windows 2000 Professional, на котором располагается данное подключение.
Считается, что в этой сети данный компьютер — единственное подключение к
Интернету, единственный шлюз в: Интернет, и что он назначает все сетевые адреса. То
есть в сети должны отсутствовать шлюзы, контроллеры домена, DNS- и DHCP-серверы, а
остальные компьютеры должны быть настроены на автоматическое получение IP-адреса.
Когда разрешается совместное использование подключения, сетевой адаптер,
связанный с малой офисной сетью, получает новый статический IP-адрес. Существующие
подключения, использующие TCP/IP на компьютере с совместным использованием
соединения, будут потеряны и должны быть восстановлены вручную.
Построение сетей TCP/IP на базе Windows 2000
Архитектура TCP/IP в Windows 2000
Семейство TCP/IP-- стандартный набор сетевых протоколов, предназначенных для
управления передачей данных между сетевыми компьютерами. Реализация TCP/IP от
Microsoft, позволяет осуществлять взаимодействие компьютеров с Windows 2000 и
устройств с другим ПО компании Microsoft, а также с системами под управлением ОС,
созданных не фирмой Microsoft (например, NIX). TCP/IP- основной набор протоколов для
множества частных глобальных сетей, которые объединяют локальные сети корпораций.
Протокол TCP/IP вообще и его реализация в Windows 2000 имеют следующие
достоинства:
 Стандартный, маршрутизируемый сетевой протокол, который является
наиболее полным и доступным общепринятым протоколом. Все современные
операционные системы поддерживают TCP/IP, и самые крупные сети
используют TCP/IP для организации их основного трафика.
 Технология объединения разнородных систем. Доступно множество
стандартных утилит для организации взаимодействия и передачи данных между
разнородными системами, включая протокол передачи файлов FTP протокол
эмуляции терминала (Telnet). Некоторые стандартные утилиты поставляются с
Windows 2000.
 Технология, позволяющая подключать сеть или одиночный компьютер на базе
Windows NT к глобальной сети Интернет. TCP/IP, протокол "точка-точка"
(РРР), протокол туннелирования "точка-точка" (РРТР) и архитектура Windows
Sockets обеспечивают необходимую основу для организации подключения к
Интернету и использования всех служб Интернета.
 Основа
для
организации
устойчивого,
масштабируемого,
межплатформенного, клиент-серверного взаимодействия.
В TCP/IP
поддерживается интерфейс Windows Sockets, который является реализацией в
среде Windows широко распространенного интерфейса Berkeley Sockets,
используемого для создания сетевых приложений.
TCP/IP и сетевая архитектура Windows 2000
Архитектура TCP/IP в операционной системе Windows 2000 обеспечивает
интегрированную, не зависящую от протоколов поддержку работать с сетями: работу
прикладных программ, работу с файлами, печать и другие услуги поверх любого сетевого
протокола, который поддерживает Интерфейс транспортного драйвера (Transport Driver
Interface, TDI).
Протоколы отвечают за упаковку сетевых запросов к приложениям в
соответствующие форматы и отправку этих запросов на соответствующий сетевой
адаптер посредством интерфейса NDIS. NDIS позволяет использовать несколько сетевых
протоколов поверх разнообразных типов сред и сетевых адаптеров.
В сочетании с транспортно-независимой архитектурой Windows 2000 протоколы
TCP/IP могут предоставлять системам на базе Windows возможности работы с сетями.
TCP/IP-протоколы дают компьютерам под управлением Windows 2000, Windows NT,
Windows 9x и Windows for Workgroups прозрачный доступ друг к другу и позволяют
связываться с другими системами, входящими в сети предприятий.
Новые возможности TCP/IP в Windows 2000
Протокол TCP/IP претерпел ряд изменений в Windows 2000 по сравнению с
предыдущей версией операционной системы. Усовершенствована работа с
широкополосными локальными и глобальными вычислительными сетями:
 Поддержка окна передачи большого размера. Эта возможность улучшает
производительность TCP/IP в случае, когда передается большое количество
данных или не требуется передача подтверждения при связи между, двумя
компьютерами в течение длительного периода времени.
 Выборочные подтверждения. Эта возможность позволяет сетям быстро
восстанавливать свою работоспособность после сетевого конфликта или
временного сбоя в физической среде. Получатель может выборочно
подтверждать или требовать повторную передачу у отправителя только тех
пакетов, которые были опущены или повреждены во время передачи данных.
 Лучшая оценка времени кругового пути (Round Trip Time, RTT). Эта
возможность повышает эффективность стека протоколов TCP/IP, позволяя
точно оценивать время, затрачиваемое на путешествие пакета туда и обратно
(RTT) между двумя хостами сети.
Службы ATM
Понятие Asynchronous Transfer Mode (ATM, асинхронный режим передачи)
описывает ряд связанных и стандартизованных технологий. ATM отличается от других
существующих технологий ЛВС и ГВС по многим параметрам. Технология ATM была
специально разработана для поддержки быстродействующих коммуникаций. ATM
позволяет эксплуатировать высокоскоростные сети, наиболее эффективно управляя
использованием полосы пропускания, сохраняя при этом гарантированное качество
обслуживания для пользователей и приложений со строгими требованиями к
обслуживанию.
Рассмотрим понятие "асинхронный режим передачи".
 Асинхронный. Это означает, что доступная ширина полосы пропускания сети
не разделена на фиксированные каналы или слоты, задаваемые при помощи
механизма
синхронизации.
Устройства,
взаимодействующие
через
асинхронные коммуникации, не ограничены точным значением скорости
передачи. Отправитель и получатель договариваются о скорости обмена
информацией исходя из аппаратных ограничений и собственной способности
поддерживать надежную передачу.
 Режим передачи. Этот термин описывает способ организации обмена
информацией. В ATM для структурирования и упаковки данных для передачи
используется концепция малых ячеек фиксированной длины. Механизм ATM с
использованием ячеек, в отличие от механизма передачи пакетов переменной
длины, который применяется в наиболее старых из существующих на данный
момент сетевых технологий, гарантирует установление и управление
соединениями так, чтобы никакой поток данных или соединение не могло бы
монополизировать путь передачи данных.
Достоинства ATM
ATM обеспечивает управление качеством обслуживания в тех сетях, где должны
присутствовать несколько типов информации (например, данные, голос, а также видео и
звук в реальном времени). ATM позволяет передавать поток каждого из этих типов
информации через одно сетевое соединение.
Преимущества ATM:
 Высокоскоростная связь. В отличие от традиционных технологий работы с
сетями типа ЛВС на базе Ethernet и служб уровня Т в WAN, технология ATM не
имеет физических или архитектурных ограничений, которые не позволяют
(или, по крайней мере, усложняют этот переход) перейти к более высоким
скоростям передачи данных. Современные продукты ATM обеспечивают
поддержку передачи данных на скоростях от 25 Мбит/с по неэкранированной
витой паре (UTP) и экранированной витой паре (STP), 155 Мбит/с по среде UTP
и оптоволокну, и от 622 Мбит/с до 4,8 Гбит/с (только по оптоволоконной
среде).
 Служба с установлением логического соединения, подобно традиционной
телефонии. Подобно традиционным телефонным службам, ATM использует
модель обслуживания с установлением логического соединения. Поскольку
стандарты ATM формализованы организацией ITU, телефонные компании во
всем мире могут применять высокоскоростную технологию ATM вместо
сетевых инфраструктур с гарантией, что все существующие телефонные
службы и все приложения могут быть приспособлены к новой сети. В
настоящее время телефонные компании в Соединенных Штатах перевели более
70% внутренних сетей на ATM. Технология ATM направлена на то, чтобы стать
в
скором
времени
глобальным
стандартом
для
телефонии.
Чтобы сохранить полную поддержку традиционных телефонных служб (голос,
факс и различные услуги АТС), службы ATM с установлением логического
соединения гарантируют, что все используемые в настоящее время приложения
телефонии, которые поддерживаются Общественными коммутируемыми
телефонными сетями (Public Switched Telephony Networks, PSTN), будут
поддерживаться и в дальнейшем.
 Быстрая аппаратная коммутация. Поскольку весь трафик ATM передается в
малых ячейках фиксированной длины (точно 53 байта), процесс маршрутизации
трафика во взаимосвязанных сетях может происходить быстро, в отличие от
других моделей взаимосвязи сетей, например, TCP/IP. В ATM весь трафик
передается с использованием коммутации, а не маршрутизации. Коммутация
ячеек в ATM является более простым и более однородным процессом по
сравнению с традиционной маршрутизацией, используемой в сетях передачи
пакетов,
например
Ethernet
и
TCP/IP.
В сетях с передачей пакетов маршрутизаторы должны использовать
программное обеспечение для правильной обработки ряда изменений в потоке
передачи, например, для определения издержек различных маршрутов, для
измерения длины пакета, для фрагментирования пакета, для передачи пакетов в
правильном
порядке
и
для
пересборки
пакетов.
В качестве замены традиционных методов маршрутизации ATM использует
простой процесс коммутации, основанный на концепции виртуальных каналов
(Virtual Circuit Connections, VCC). VCC формируются при помощи ряда
назначенных идентификаторов виртуального пути (Virtual Path Identifier, VPI)
и идентификаторов виртуального канала (Virtual Ciruit Identifier, VCI) между
коммутаторами. Фактические пути и каналы, используемые каждым
коммутатором, идентифицируются зарезервированным числом битов в
заголовке
каждой
ячейки
ATM.
Поскольку информация VPI/VCI всегда появляется в одном и том же месте
каждой ячейки, коммутаторы ATM могут быстро считывать числа VPI/VCI
входящей ячейки, коммутировать эту ячейку, заменяя эти числа на новые числа
VPI/VCI, и немедленно передавать эту ячейку через выходной порт. Поскольку
поток ячеек ATM может быть более однородным и предсказуемым, то для
выполнения функций коммутации может использоваться аппаратный механизм
синхронизации.
 Единый универсальный сетевой транспорт. ATM поддерживает единый
способ передачи данных, позволяющий связывать сети любых размеров и
масштабировать
их
в
будущем.
При использовании ATM в качестве глобального транспорта для всех сетей не
нужно обеспечивать дополнительную трансляцию и шлюзы между
традиционными транспортами для ЛВС (типа Ethernet или Token Ring) и
транспортами для ГВС (типа Х.25, Frame Relay и Т1 или выделенных линий),
что создает единую "бесшовную" сеть, полностью реализуемую на основе
ATM.
Хотя чистые ATM-сети в настоящее время встречаются не так уж часто, ATM
обеспечивает возможность взаимодействия с существующими сетевыми
технологиями типа Ethernet и Token Ring при помощи службы Эмуляции ЛВС
(LAN Emulation, LANE) и поддержки новых стандартов TCP/IP поверх ATM,
которые позволяют перейти к ATM, сохраняя прозрачные соединения с
клиентами,
использующими
унаследованные
технологии.
Например, удаленный пользователь с домашнего компьютера, используя новые
технологии типа Asymmetric Digital Subscribers Line (ADSL, асимметричная
цифровая абонентская линия) или кабельный модем, мог бы устанавливать
соединение с корпоративной частной ЛВС на базе ATM в удаленном офисе и
обмениваться информацией, используя только ATM. Такая схема возможна,
поскольку сети ГВС, в настоящее время развернутые телефонными компаниями
в США и в других странах, для обеспечения традиционных телефонных служб
переведены на ATM.
 В одном сетевом подключении можно безболезненно смешивать данные
разных типов. В большинстве случаев голос, видео и обычные данные
передаются по раздельным сетям из-за специфических требований и
характеристик для каждого из этих типов информации. В ATM все эти типы
информации могут надежно передаваться через единое сетевое подключение.
ATM использует концепцию категорий обслуживания (service categories) и
установление договоров (контрактов) на определенное качество обслуживания
(Quality of Service, QoS) между конечными пользователями ATM и
коммутаторами для того, чтобы получить надежную службу передачи данных.
 Гибкое и эффективное распределение ширины полосы пропускания сети.
Даже при том, что технология ATM обеспечивает реальную ширину полосы
пропускания
наиболее
требовательным
современным
приложениям
мультимедиа, она также позволяет быстро выбрать нужную ширину полосы
пропускания для тех соединений, где это необходимо более всего ATM
использует
категории
обслуживания,
чтобы
назначить
уровни
производительности
для
каждого
соединения.
Это позволяет использовать ATM для того, чтобы определить приоритет и
качество обслуживания для каждого сетевого соединения ATM с требуемой
точностью. Все категории обслуживания ATM на основе параметров QoS
измеряют производительность канала и качество обслуживания, которое
предписано на аппаратном уровне адаптерами и коммутаторами ATM.
Тема 4.
Менеджмент создания информационных систем
Обследование деятельности предприятия
При создании информационных систем часто предприятия используют консалтинговые услуги. Консалтинг является
компонентом
информационного
менеджмента
как
составляющая
процесса
создания
автоматизированных
информационных систем.
Консалтинг — это деятельность специалиста или целой фирмы (КД), занимающихся стратегическим планированием
проекта, анализом и формализацией требований к информационной системе, созданием системного проекта, иногда —
проектированием приложений.
Но все это осуществляется до этапа собственно программирования или настройки каких-то уже имеющихся
комплексных систем управления предприятием, выбор которых и осуществляется на основе системного проекта. Сюда
не входит системная интеграция. Консалтинг предваряет и регламентирует названные этапы.
Основные цели разработки консалтинговых проектов:
представление деятельности предприятия (ДП) и принятых в нем технологий в виде иерархии
диаграмм, обеспечивающих наглядность и полноту их отображения;
2) формирование на основании анализа предложений по реорганизации организационно-управленческой
структуры;
3) упорядочение информационных потоков (в том числе документооборота) внутри предприятия;
4) выработка рекомендаций по построению рациональных технологий работы подразделений
предприятия и его взаимодействию с внешним миром;
5) анализ требований и проектирование спецификаций корпоративных информационных систем;
6) рекомендации и предложения по применимости и внедрению существующих систем управления
предприятиями, прежде всего классов MRP-II (manufacturing resource planning) и ERP (enterprise
resource planning).
Структурный подход к разработке консалтинговых проектов приведен на рис. 4.1.
1)
Этап 1 (анализ первичных требований и планирование работ) предваряет инициацию работ над проектом. Его
основные задачи:
1)
2)
3)
4)
5)
Важнейшими
предварительное изучение задачи;
анализ первичных бизнес-требований;
предварительная экономическая оценка проекта;
построение плана-графика выполнения работ;
создание и обучение совместной рабочей группы.
на данном этапе являются и организационные мероприятия: должны быть изданы соответствующие
приказы по проведению работ, назначены ответственные по направлениям - без подобной поддержки со стороны
руководства предприятия бессмысленно вообще затевать консалтинговый проект.
Первый шаг собственно разработки — предварительное изучение задачи, которое должно ответить на ряд вопросов:
1.
2.
3.
В чем заключаются недостатки существующей ситуаций?
Какие улучшения возможны?
На кого окажет влияние новая система?
Рис 4.1 Структура подхода
На данном этапе целесообразно построить обзорную диаграмму потоков данных для оценки существующей
ситуации с целью ее использования для подгонки всех фрагментов друг к другу и выявления недостатков.
В результате предварительного изучения аналитик должен разумно оценить преимущества внедрений новой
системы, а также обосновать временные затраты и стоимость следующего шага разработки — детального изучения.
Результаты предварительного изучения рассматриваются руководством соответствующего уровня, на их основе может
быть санкционирована возможность детального изучения.
Детальное изучение, включающее этапы 2—4, строится на фактах, выявленных во время предварительного изучения
и проведения обследования деятельности предприятия, и предполагает более детальное и точное документирование
ограничений существующей системы, а также уточнение функций этой системы до уровня, необходимого для
написания спецификаций новой (модернизированной) системы.
В рамках этапа 2 (проведение обследования деятельности предприятия) осуществляется:
1) предварительное выявление требований, предъявляемых к будущей системе;
2) определение организационной и топологической структур предприятия;
3) определение перечня целевых задач (функций) предприятия;
4) анализ распределения функций по подразделениям и сотрудникам;
5) определение перечня применяемых на предприятии средств автоматизации.
При этом выявляются функциональная деятельность каждого из подразделений предприятия и функциональные
взаимодействия между ними, информационные потоки внутри подразделений и между ними, внешние по отношению к
предприятию объекты и внешние информационные взаимодействия.
По окончании обследования строится и согласуется с заказчиком предварительный вариант функциональной модели
предприятия, включающей идентификацию внешних объектов и информационных взаимодействий с ними, а также
детализацию до уровня основных видов деятельности предприятия и информационных связей между этими видами.
На этапе 3 (построение моделей деятельности предприятия) осуществляется обработка результатов обследования и
построение моделей деятельности предприятия следующих двух видов:

модели «как есть», представляющей собой «снимок» положения дел на предприятии (организационная
структура,
взаимодействия
подразделений,
принятые
технологии,
автоматизированные
и
неавтоматизированные бизнес-процессы и т.д.) на момент обследования и позволяющей понять, что
делает и как функционирует данное предприятие с позиций системного анализа, а также на основе
автоматической верификации выявить ряд ошибок и узких мест и сформулировать ряд предложений по
улучшению ситуации;
 модели «как должно быть», интегрирующей перспективные предложения руководства и сотрудников
предприятия, экспертов и системных аналитиков и позволяющей сформировать видение новых
рациональных технологий работы предприятия.
Главный результат детального изучения — этап 4 — построение системного проекта (модели требований),
являющеюся первой фазой разработки собственно информационной системы (именно фазой анализа требований к
системе), на которой требования заказчика уточняются, формализуются и документируются. Системный проект
строится на основе модели «как должно быть» и результатов обследования предприятия в части выявления требований к
будущей системе.
При презентации системного проекта аналитик должен быть готов услышать больше критических замечаний, чем
при использовании традиционных подходов, так как диаграммы легче понять, и обнаружить какие-либо несоответствия
и ошибки. В результат презентации принимается решение о продолжении разработки или ее прекращении, а также
устанавливается сумма бюджета проекта, поэтому аналитику необходимо создать несколько альтернативных моделей
систем, имеющих разный набор преимуществ и предполагающих различные капиталовложения.
По завершении данного этапа (после согласования системного проекта с заказчиком) изменяется роль консультанта.
Отныне он становится на сторону заказчика, одной из его основных функций на всех последующих этапах работ будет
контроль на соответствие требованиям, зафиксированным в системном проекте.
После выбора системного проекта на основе выявленных и согласованных требований осуществляется разработка
предложений по автоматизации — этап 5, включающий:
составление перечня автоматизированных рабочих мест предприятия и способов взаимодействия
между ними;
2) анализ применимости существующих систем управления предприятиями (прежде всего классов MRP
и ERP) для решения требуемых задач и формирование рекомендаций по выбору такой системы;
3) совместное с заказчиком принятие решения о выборе конкретной системы управления предприятием
или разработке собственной системы;
4) разработка требований к техническим средствам;
5) разработка требований к программным средствам;
6) разработка предложений по этапам и срокам автоматизации.
На этапе 6 на основании принятых решений по автоматизации осуществляется преобразование системного проекта в
1)
технический проект (модель реализации), включающее следующие действия:
уточнение логической модели (разработка подробной логики каждого процесса с использованием
диаграмм потоков данных и спецификаций процессов);
2) проектирование физической базы данных;
3) построение иерархии функций модулей, подлежащих программированию;
4) оценка затрат на реализацию.
Перечисленные работы должны выполняться консультантами совместно с проектировщиками системы: именно
1)
здесь и находится граница, разделяющая консалтинг и разработку. Тем не менее желательно, чтобы на этапе реализации
системы консультант также действовал в интересах заказчика, а именно: контролировал соответствие создаваемой
программной системы системному и техническому проектам, а также участвовал в работах по ее расширению и
модификации, так как планирование расширений должно осуществляться на основе модели требований.
Проведение обследования. Обследование — важнейший и определяющий этап выполнения консалтинговых
проектов, на его основе осуществляется вся последующая деятельность. По окончании обследования строится и
согласуется
с
заказчиком
предварительный
вариант
функциональной
модели
предприятия,
включающей
идентификацию внешних объектов и информационных взаимодействий с ними, а также детализацию до уровня
основных видов деятельности предприятия и информационных связей между этими видами, в дальнейшем на основании
согласованных моделей верхнего уровня и осуществляется построение детальных моделей.
Необходимо отметить, что каждый из участвующих в проекте системных аналитиков должен обследовать не более
2—3 видов деятельности предприятия (таких, как, например, учет кадров, бухгалтерия, маркетинг, ремонт
оборудования, перевозки и т.п.), для того чтобы тщательно в них разобраться. Современное предприятие является
сложной системой, состоящей из крупных взаимоувязанных подсистем (видов деятельности), а возможности человека в
одновременном охвате большого количества таких подсистем ограничены.
Исходной информацией при проведении обследования и выполнении дальнейших этапов служат:
1)
2)
3)
4)
5)
6)
7)
8)
данные по организационной структуре предприятия;
информация о принятых технологиях деятельности;
стратегические цели и перспективы развития;
результаты интервьюирования сотрудников (от руководителей до исполнителей нижнего звена);
предложения сотрудников по усовершенствованию бизнес процессов предприятия;
нормативно-справочная документация;
данные по имеющимся на предприятии средствам и системам автоматизации;
опыт системных аналитиков в части наличия типовых решений.
При проведении обследования целесообразно применять следующие методы:
1.
2.
3.
Анкетирование
анкетирование;
сбор документов;
интервьюирование.
— начальный этап обследования, он предваряет выезд группы системных аналитиков на
предприятие. Анкеты позволяют составить первоначальное представление о сферах деятельности предприятия, что дает
возможность спланировать дальнейшее распределение работ группы аналитиков. Анкеты рассылаются руководителям
структурных подразделений и содержат графы для идентификации фамилии и должности анкетируемого, отдельно в
анкетах излагается просьба приложить шаблоны документов, с которыми работают сотрудники соответствующего под
разделения. Список вопросов ограничен 15—20 вопросами с тем, чтобы вся анкета не занимала более двух листов.
Примерный вариант анкеты приведен ниже
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
ФИО руководителя подразделения, телефон.
Координаты контактного лица (к кому в отсутствие или при занятости руководителя можно
обращаться).
Каковы (с позиций вашего подразделения) должны быть цели создания интегрированной системы
управления предприятием?
Основные функции подразделения.
Какая информация поступает из других подразделений (заявки, запросы, отчеты и т.п.)?
Какая информация передается в другие подразделения?
Какая информация формируется (рождается) в подразделении?
С какими внешними предприятиями (банк, заказчик, поставщик и т.п.) взаимодействует
подразделение и какой информацией обменивается?
Физическое представление информационных потоков и хранилищ (документ, дискета, сеть,
журнал, картотека и т.п.).
Время хранения информации.
Документы от и для руководства.
Штатная структура и квалификация кадров.
Техническое оснащение подразделения (компьютеры, сеть, модем и т.п.).
Используемые программные продукты.
Подпись.
Просьба приложить:
1) положение о подразделении;
2)
набор документальных форм без внутреннего наполнения, т.е. используемые формы, бланки и др.
(например, карточку складкою учета, отчет по форме N, наряд-задание, товарно-транспортную накладную).
Сбор документов должен осуществляться на всех этапах проведения обследования; соответствующие формы, бланки
и т.п. в дальнейшем окажут неоценимую услугу при разработке информационной модели предприятия (выявлении
сущностей информационной модели и наполнении их атрибутикой). В дальнейшем целесообразно подготовить альбом
форм с разбивкой их по сфере деятельности предприятия.
Интервьюирование — важнейший и необходимый метод обследования, только с его помощью возможно
разобраться во всех тонкостях применяемых на предприятии технологий. Современное предприятие — сложнейшая
система, как оно функционирует, не знает ни один человек. Конечно, руководство представляет ситуацию в целом, с
другой стороны, клерк досконально знает свою деятельность, но полной картины не имеет никто. И только
интервьюирование представителей всех звеньев организационной структуры позволит выявить и в дальнейшем
формализовать эту картину.
С другой стороны, интервьюирование является и наиболее сложной задачей: необходимо найти контакт с
сотрудником и направить беседу в необходимое для аналитика русло. Ниже предлагаются несколько общих
рекомендаций, касающихся линии поведения аналитика при интервьюировании:

тезис в начале беседы — я ничего (или почти ничего) не знаю о вашей работе, расскажите как можно
подробнее, чем вы занимаетесь;

правило 1 — если вам начали подробно рассказывать технологию работы, ни в коем случае не
перебивайте, необходимые уточнения можно сделать и в конце беседы,
 правило 2 — если в беседе участвуют несколько аналитиков, вести беседу и задавать уточняющие
вопросы должен один из них, неясные для других вопросы проясняются в конце беседы;
 правило 3 — даже если вы прекрасно знаете предметную область, не говорите много сами и не учите
интервьюируемого: в любом случае выявляются тонкости и детали, специфичные для данного
предприятия и, естественно, вам не известные.
В принципе этих и подобных им правил достаточно для выявления в ходе беседы необходимой аналитику
информации приблизительно у 90% интервьюируемых, а этого более чем достаточно в соответствии с законом «20 на
80». Тем не менее постараемся составить основанную на опыте типизацию остальных 10% и предложить возможные
действия по выходу из тупика:
1) «отказник» — как правило, квалифицированный специалист, осознающий свою незаменимость. Обычно
руководству известен его характер, поэтому необходимы жесткие меры: либо данная деятельность не будет включена в
модель, либо она будет промоделирована на основании опыта и соображений здравого смысла;
2)
«говорун» — как правило, руководитель среднего звена, понимающий, что по-старому работать нельзя, и
хватающийся за любую возможность улучшить ситуацию. Очень полезный для поддержки проекта человек, тем не
менее в беседе готов бесконечно обсуждать свои трудности и проблемы, получить от него необходимую для построения
модели информацию практически невозможно. Единственный способ работы с ним — обсуждение уже построенной
(пусть примитивной и во многом ошибочной) модели с целью ее доводки;
3) «балласт» — человек, давно работающий на предприятии и непонятно чем занимающийся. На вопросы «Какие
функции вы выполняете?», «С какими документами вы работаете?» агрессивно повторяет, как попугай: «Я делаю все»,
«Со всеми документами», «Все документы ко мне приходят и все уходят». Какой-либо информации получить не
удается по причине ее отсутствия. Естественно, никакого отражения подобной «деятельности» в модели не
производится;
4) человек, занимающий экзотическую и малопонятную должность. Представляет собой модификацию варианта 3) с
той лишь разницей, что реально деятельность существует и, следовательно, должна быть отражена в модели;
5) «мелкая сошка» — человек, не привыкший к проявлению интереса к себе и своей работе и занимающий низшую
должность. При должном терпении реально получение того небольшого куска информации, которым он владеет. При
обследовании диспетчерской службы одного из северных предприятий на одной из удаленных точек аналитик имел
неосторожность во время непродолжительной беседы включить диктофон. Беседа была тут же прервана, и аналитику
пришлось ждать минут сорок, пока интервьюируемая приводила себя в порядок: накладывала косметику и делала
прическу!
Какую же информацию нужно выявлять прежде всего во время интервьюирования?
1.
2.
3.
4.
5.
6.
Необходимо ограничить контекст системы; с этой целью должны быть определены все внешние
объекты, с которыми моделируемое предприятие взаимодействует, технологии взаимодействия со
стороны предприятия, а также информационные (и, возможно, материальные) потоки,
обеспечивающие эти взаимодействия.
Следует установить и детально проанализировать реальные технологии работы предприятия:
нормативно-справочная документация (если она имеется) описывает их неполно.
Должны быть определены реальные функции подразделений и их взаимосвязи и
взаимозависимости, поскольку положения о подразделениях такую информацию не содержат.
Выявляются и специфицируются все информационные хранилища (в том числе и бумажные:
картотеки, архивы и т.п.).
Оценивается аппаратно-техническая база предприятия, а также исследуется работающее на ней
программное обеспечение.
Собираются статистические данные по бизнес-процессам предприятия.
Остановимся на последнем более подробно.
Статистические данные при проведении обследования надо собирать по каждому объекту будущей модели: потоку
данных, элементу данных, процессу, хранилищу данных, внешней сущности и т.п. Так, на этане анализа моделей
наличие подробной статистики обеспечит их адекватную верификацию на полноту и непротиворечивость и позволит на
начальных этапах выявить ошибки и узкие места в построенных моделях. В следующих пунктах будет показано, как эти
статистические данные работают на дальнейших этапах, начиная с этапа выработки предложений по автоматизации и
заканчивая собственно разработкой или внедрением выбранной системы.
1) Составные данные. Для составных данных статистика co6ирается, как правило, лишь для итеративных
(повторяющихся) компонентов: необходимо точно знать количество итераций для каждого из них (например, заказ на
книги включает в себя перечень заказанных книг с их атрибутами), поэтому для формирован требований к функции
распечатки соответствующего бланка необходимо знать: сколько книг обычно заказывается? как час производится
нетипичный заказ и каковы его размеры? сколько авторов обычно бывает у книги?..
Статистика по итеративным компонентам внутри составных данных в дальнейшем будет использоваться для
проектировании экранов, отчетов и, естественно, при проектировании базы данных.
2) Элементы данных. О каждом элементе данных необходимо знать формат данных и допустимые значения этого
элемента. Формат (включая тип) и физическая длина очень полезны при проектировании экранных форм и определении
размеров баз данных.
3) Потоки данных. Такие характеристики потока, как скорость и интенсивность, являются необходимыми при
определении требований к аппаратным (техническим) средствам. Кроме того, для любого составного потока данных
полезно знать распределение компонентов внутри этого потока данных. Например, если в фирме «Рога и Копыта» заказ
определяется, как заказ = {заказ на рога / заказ на копыта}, и выясняется, что 12% всех заказов составляют заказы на
рога, 84% — на копыта, а 4% заказов — на заполнение стержней для шариковых ручек, то данная статистика может
использоваться для определения пиковых нагрузок на соответствующие обрабатывающие процессы (а также, возможно,
для принятия решения об оказании дополнительного вида услуги — upgrade стержней).
4) Процессы. Важнейшие характеристики процессов — частота и время выполнения. Именно здесь и лежит ключ к
улучшению их функционирования. Кроме того, такие сведения являются необходимыми при определении требований к
аппаратным средствам.
5) Хранилища данных. По хранилищам данных обычно собирается следующая информация: среднее количество
записей в каждом хранилище данных, количество чтений, добавлений, изменений и удалений записей по каждому из
процессов, включающих перечисленные действия. Проектировщик баз данных может использовать эту статистику для
нескольких целей: например, решить вопрос, какой ключ считать первичным, сортировать ли хранилище и по какому
ключу, решить, нужно ли завести дополнительную таблицу с целью обеспечения скорости доступа и т.д. Более того, к
этой информации потребуется обратиться и при выборе подходящей СУБД, которая сможет обеспечить необходимую
частоту и (или) гибкость доступа к данным.
Хронология доступа — также ценная информация. Так, запись о конкретном заказе, как правило, однажды создается
и однажды удаляется. Но обычно доступ к этой записи осуществляется очень часто в начале ее существования (запросы
о покупателе, счета, платежи, накладные) и крайне редко в дальнейшем (месячные и квартальные отчеты), что позволяет
своевременно осуществлять ее архивацию.
6) Внешние объекты. Наконец, необходимо собрать определенную статистику об окружении, в котором система
должна работать («ограничения окружения»). Наиболее важным здесь является количество пользователей, их способы
использования системы и географическое распределение. По этой статистике можно будет сделать заключения о
стоимости периферии, о типе системы телекоммуникаций и даже о том, как данные должны быть физически
распределены для обеспечения удаленного доступа. Другие данные об окружении могут включать температуру, уровень
шума, существующую отделку помещения, уровень радиации и т.п. Следует отметить, что часто возникает
необходимость в проведении дополнительного обследования: какие-то моменты были не до конца выяснены, где-то
возникли нестыковки, что-то было просто упущено. Обычно дополнительное обследование занимает два-три дня, и при
его проведении очень полезно обсудить с интервьюируемыми уже наработанные модели.
Построение моделей
Модели деятельности предприятия. Построение и анализ моделей деятельности предприятия относится к области
бизнес-консалтинга, включающего в себя построение моделей текущего и целевого состояния предприятия, выработку
предложений по совершенствованию его деятельности, формирование целевой программы развития предприятия и
плана перехода из текущего стояния в целевое. На данном этапе осуществляется обработка результатов обследования и
построение функциональных, информационных и, если необходимо, событийных моделей технологий работы
предприятия следующих двух видов:
 модели «как есть»;
 модели «как должно быть».
При этом переход от модели «как есть» к модели «как должно быть» обычно осуществляется следующими двумя
способами:
совершенствованием технологий на основе оценки их эффективности. При этом критериями оценки
являются стоимостные и временные затраты выполнения бизнес-процессов, дублирование и
противоречивость выполнения отдельных задач бизнес-процесса, степень загруженности сотрудников
(«легкий» реинжиниринг);
2) радикальным изменением технологий и переосмыслением; бизнес-процессов («жесткий» реинжиниринг).
Например, вместо попыток улучшения бизнес-процесса проверки кредитоспособности клиента, может
быть, следует задуматься, а нужна ли вообще такая проверка? Возможно, затраты на такие проверки
каждого из клиентов во много раз превышают убытки, которые может понести банк в отдельных случаях
недобросовестности (в случае, когда клиентов много, а суммы сделок незначительны).
Необходимость подобного перехода и повлекла за собой создание подходов к реорганизации деятельности
1)
предприятий (реинжинирингу бизнес-процессов). В данном разделе рассматривается, собственно говоря, методика
построения моделей деятельности.
В рамках создания моделей деятельности должен быть осуществлен:
анализ функциональной деятельности структурных подразделений предприятия;
анализ функционального взаимодействия структурных подразделений;
анализ внутреннего документооборота структурных подразделений; анализ информационных потоков и
информационного взаимодействия структурных подразделений;
4) анализ применяемых в настоящее время средств автоматизации как в структурных подразделениях, так и
на предприятия в целом.
По результатам анализа и моделирования осуществляется оценка эффективности деятельности структурных
1)
2)
3)
подразделений предприятия, на основе которой формируются предложения по совершенствованию его структуры,
технологий работы структурных подразделений и предприятия в целом. Критериями такой оценки должны являться:
количество потребителей продукции предприятия;
стоимость издержек производства продукции;
длительность типовых операций производства продукции;
дублирование и противоречивость функций, информационных потоков и документооборота;
стоимость и длительность выполнения отдельных шагов технологии или отдельных технологических
цепочек шагов;
6) дублирование и противоречивость выполнения отдельных шагов технологии или отдельных
технологических цепочек шагов;
7) степень загруженности структурных подразделений и должностных лиц;
8) степень загруженности оборудования, используемого при реализации отдельных шагов технологии или
технологических участков;
9) степень применения средств автоматизации при поддержке выполнения отдельных шагов технологии или
отдельных технологических цепочек шагов
Результат проведения анализа и оценки — предложения по совершенствованию деятельности предприятия, а
1)
2)
3)
4)
5)
именно:
по изменению технологий целевой и обеспечивающей деятельности предприятия, операций учета,
планирования, управления и контроля;
2) по построению рациональных технологий работы структурных подразделений предприятия с учетом
существующих автоматизированных систем;
3) по созданию перспективной организационной структуры предприятия, осуществляющей реализацию
рациональных технологий работы;
4) по изменению информационных потоков и документооборота, обеспечивающих реализацию
рациональных технологий работы;
5) по разработке проектов схем внутреннего и внешнего документооборота, проекта положения о
документообороте, проекта альбома форм входных и выходных документов.
На основе разработанных и согласованных предложений формируется целевая программа развития предприятия и
1)
план мероприятии по переходу из текущего состояния в целевое. Целевая программа развития предприятия должна
включать долгосрочные решения, цели, задачи и основные параметры развития. План мероприятий перехода из
текущего состояния в целевое содержит:
последовательность, формы, способы и время выполнения задач, поставленных структурным
подразделениям предприятия;
2) распределение сотрудников структурных подразделений и материальных средств по решаемым задачам;
3) порядок информационного и других видов взаимодействия структурных подразделений и органов
управления.
В связи с вышесказанным каждая из моделей деятельности включает:
1)
полную функциональную модель с глубиной проработки до уровня конкретного действия должностного
лица структурного подразделения предприятия;
2) информационную модель, интегрированную с функциональной моделью;
3) динамические, стоимостные, событийные и т.п. модели для осуществления соответствующих оценок.
Ниже перечислены основные виды и последовательность работ, рекомендуемые при построении моделей
1)
деятельности.
Разработка структурной функциональной модели деятельности предприятия:
 определение информационных потоков между основными процессами деятельности, связей между
процессами и внешними объектами; оценка объемов и интенсивности информационных потоков;
 разработка иерархии диаграмм, образующих структурную функциональную модель деятельности
предприятия;
 анализ и оптимизация структурной функциональной модели
2) Разработка информационной модели предприятия:
 определение сущностей модели и их атрибутов;
 проведение атрибутного анализа и оптимизация сущностей, идентификация отношений между
сущностями и определение типов отношений;
 разрешение неспецифических отношений;
 анализ и оптимизация информационной модели.
3) Разработка событийной модели предприятия:
 идентификация перечня состояний модели и определение возможностей переходов между
состояниями;
 определение условий, активизирующих переходы, и действий, влияющих на дальнейшее поведение;
 анализ и оптимизация событийной модели.
Следует отметить, что построенные модели деятельности — не просто промежуточный результат, используемый
1)
консультантом для выработки каких-либо рекомендаций и заключений. Они представляют собой самостоятельный
результат, имеющий большое практическое значение, в частности:

модели позволяют осуществлять автоматизированное и быстрое обучение новых работников
конкретному направлению деятельности предприятия (так как ее технология содержится в модели) с
использованием диаграмм;
 с их помощью можно осуществлять предварительное моделирование нового направления
деятельности с целью выявления новых потоков данных, взаимодействующих подсистем и бизнеспроцессов.
Ниже приводятся некоторые основополагающие рекомендации по структурированию моделей деятельности.
1. Основной принцип заключается в том, что структурирование должно осуществляться в соответствии со сферами
деятельности и бизнес-процессами предприятия, а не в соответствии с его организационной структурой. Именно бизнеспроцессы представляют ценность для клиента, и именно их улучшением предстоит в дальнейшем заниматься
консультанту. Модель, основанная на бизнес-процессах, содержит в себе (не всегда в явном виде) и организационную
структуру предприятия.
2. Верхний уровень модели отражает только контекст системы — взаимодействие моделируемого единственным
контекстным процессом предприятия с внешним миром и ничего более.
3. На втором уровне модели воспроизводятся основные этапы деятельности предприятия и их взаимосвязи.
Например, для автотранспортного предприятия одним из решений может быть выделение следующих видов
деятельности: Эксплуатация автотранспорта, Ремонт и техническое обслуживание, Контроль безопасности, Управление
производством, Обеспечивающая деятельность. В случае большого количества сфер деятельности некоторые из них
можно вынести на третий уровень модели. Так, Обеспечивающая деятельность может включать в себя Учет кадров,
Бухгалтерский учет, Экономическое планирование, Материально-техническое снабжение, Складской учет и т.п. Но в
любом случае под деятельность необходимо отводить не более двух уровней модели.
4. Каждая деятельность в свою очередь детализируется на бизнес-процессы (желательно, единственного уровня).
Например, деятельность по Учету кадров включает в себя такие бизнес-процессы: Прием на работу, Увольнение и т.п.
5. Дальнейшая детализация бизнес-процессов осуществляется посредством бизнес-функций. Так, процесс Прием на
работу содержит в себе функции: Прием заявления, Оформление приказа, Регистрацию и др. Обычно для
моделирования бизнес-функции до статочно 2—3 уровней детализации, завершающейся описанием элементарного
алгоритма с помощью миниспецификации.
6. Таким образом, общее число уровней в модели не должно превышать 6—7. Практика показывает, что этого
вполне достаточно для построения полной модели деятельности современного предприятия любой отрасли.
Разработка системного проекта. Создание системного проекта (т.е. модели требований к будущей системе) —
первая фаза разработки собственно информационной системы (фаза анализа требований к системе), на которой
требования заказчика уточняются, формализуются и документируются. Системный проект строится на основе модели
«как должно быть» и результатов обследования предприятия в части выявления требований к будущей системе.
Фактически на данном этапе дается ответ на вопрос: «Что должна делать будущая система?». Именно здесь лежит
ключ к успеху всего проекта автоматизации. В практике создания больших программных систем известно немало
примеров неудачной реализации именно из-за неполноты и нечеткости определения системных требований.
На этом этапе определяются:
архитектура системы, ее функции, внешние условия ее функционирования, распределение функций между
аппаратной и программной частями;
2) интерфейсы и распределение функций между человеком и системой;
3) требования к программным и информационным компонентам системы, необходимые аппаратные ресурсы,
требования к базе данных, физические характеристики компонент системы, их интерфейсы;
4) состав людей и работ, имеющих отношение к системе;
5) ограничения в процессе разработки (директивные сроки завершения отдельных этапов, имеющиеся
ресурсы, организационные процедуры и мероприятия, обеспечивающие защиту информации).
В рамках системного проектирования должно быть осуществлено:
1)
1)
2)
3)
4)
5)
определение состава, структуры и характеристик функциональных задач в пределах деятельности
структурных подразделений;
определение состава и структуры программных средств автоматизации технологии решения задач с
учетом существующих средств в структурных подразделениях;
определение структуры и характеристик информационного обеспечения технологии решения задач;
разработка технических решений по построению информационного обеспечения (логических структур баз
данных, структур классификаторов);
разработка состава автоматизируемых процедур документооборота.
Системный проект должен включать:
1)
2)
3)
4)
5)
6)
полную функциональную модель требований к будущей системе;
комментарии к функциональной модели (спецификации процессов нижнего уровня в текстовом виде);
пакет отчетов и документов по функциональной модели, включающий характеристику объекта
моделирования, перечень подсистем, требования к способам и средствам связи для информационного
обмена между компонентами, требования к характеристикам взаимосвязей системы со смежными
системами, требования к функциям системы;
концептуальную модель интегрированной базы данных (пакет диаграмм);
архитектуру системы с привязкой к концептуальной модели;
предложения по организационной структуре для поддержки системы.
Таким образом, системный проект содержит функциональную, информационную и, возможно, событийную модели
требований к будущей системе. Виды и последовательность работ при построении этих моделей требований аналогичны
соответствующим работам по построению моделей деятельности. Дополнительно системный проект включает в себя
техническое задание на создание информационной системы.
Системный проект, позволяет:
1)
2)
3)
4)
5)
описать, увидеть и скорректировать будущую систему до того, как она будет реализована физически;
уменьшить затраты на разработку и внедрение системы;
оценить разработку по времени и результатам;
достичь взаимопонимания между всеми участниками работы (заказчиками, пользователями,
разработчиками, программистами и т.д.);
улучшить качество разрабатываемой системы, а именно: создать оптимальную структуру
интегрированной базы данных, выполнить функциональную декомпозицию типовых модулей.
Техническое проектирование
Предложения по информатизации. После построения системного проекта, содержащего требования к будущей
системе, на его основе осуществляется разработка предложений по информатизации предприятия, включающая:
1)
2)
3)
4)
5)
6)
7)
составление перечня автоматизированных рабочих мест предприятия, их состава и структуры, а также
способов и схем информационного взаимодействия между ними;
разработку требований к техническим средствам;
разработку требований к программным средствам;
разработку топологии, состава и структуры локальной вычислительной сети;
анализ имеющихся на рынке систем управления предприятием с учетом их соответствия системному
проекту и формирование рекомендаций по выбору такой системы;
совместное с заказчиком принятие решения о выборе конкретной системы управления предприятием (или
отдельных ее элементов) или о разработке собственной системы;
разработку предложений по этапам и срокам внедрения информационной системы.
Далее рассматриваются общие соображения по выбору программного и технического (аппаратного) обеспечения,
который необходимо сделать прежде, чем приступить к детальному проектированию.
1) Обозначение границ реализации. Практически любая система может быть разбита на части, отражающие четыре
основных типа реализации систем: ручную, пакетную, диалоговую, реального времени. Из этих четырех типов первый
реализуется людьми, остальные три являются автоматическими реализациями системы. Рассмотрим критерии
назначения частям системного проекта наиболее приемлемых для них типов реализации.
Ручная реализация имеет три основных преимущества перед автоматической:

процессы не требуется заранее точно определять. По крайней мере они могут определяться не так
тщательно, как при автоматической реализации: люди хорошо знают, как заполнить пробелы в
спецификации;
 ручная система может откликаться на неожидаемые запросы, а не только на заранее планируемые.
Например, ручная система бронирования авиабилетов может ответить на запрос о возможности парковки
автомобиля около аэропорта
 система может быть реализована в окружении, где автоматизация невозможна по целому ряду причин,
например, психологических: хотя и возможно полностью автоматизировать процесс предоставления
ссуды, люди не могут примириться с тем, что их прошения беспристрастно отклонены машиной.
После определения границ ручной реализации необходимо решить, какая часть системы будет пакетной, а какая
диалоговой. Для большинства современных приложений вся информационная система должна быть диалоговой, если
только не доказано противное. Соответствующее заключение может быть сделано на основе собранных статистических
данных, например скорости поступления запросов и частоты изменения данных. В качестве примеров причин для
пакетной реализации можно привести следующие:

некоторые запросы требуют длительной работы со срезом базы данных за определенный период (годовой
отчет, пересылка накопленной информации и т.п.);
 некоторые отклики (например, отчеты о продажах) содержат большое количество статичных данных,
актуальность которых не изменяется в течение дней или даже недель.
Следующий шаг — выделение частей, реализуемых как подсистемы реального времени. Существует два
принципиальных отличия системы реального времени от просто диалоговой системы. Первое из них связано с
концептуальным уровнем: в системе реального времени время поступления события в систему само по себе несет
определенную информацию, которая не может быть закодирована. Второе связано с уровнем реализации: время отклика
системы реального времени является критичным и сопоставимым со скоростью выполнения технологических операций.
В целом рекомендуется реализовать как подсистемы реального времени те части системы, из которых должен быть
исключен человек, т.е. те части, где приоритетны следующие факторы: скорость (например, противоракетная оборона),
опасность (например, контроль радиоактивности), утомляемость (работа авиадиспетчера).
2)Выбор подходящих технических средств. Разработав системный проект и определив границы реализации, можно
начинать выбор аппаратной платформы, на которой будет функционировать система (или по крайней мере сужать
область для такого выбора).
3) Анализ и выбор существующей системы. Зная типы подсистем и потенциальную аппаратную платформу, можно
приступать к поиску коммерческих пакетов, удовлетворяющих требованиям, выявленным и зафиксированным на этапе
системного проектирования, и которые могут справиться с размерами и мощностью, определяемыми собранной
статистикой. Следует отметить, что к такому выбору необходимо подходить обосновано, т.к. стоимость
интегрированной системы (включая ее внедрение на предприятии), в комплексе решающей стоящие перед
предприятием задачи, может составлять сотни тысяч и миллионы долларов
Ниже перечислены некоторые из критериев выбора готовой системы:
1)
2)
3)
4)
5)
6)
Помимо
поддержка большинства функций, выявленных при анализе требований;
поддержка концептуальной модели данных;
наличие высокоуровневых механизмов разработки для компенсации отсутствующих данных и функций;
функционирование на различных аппаратных платформах,
достаточные размеры внутренних таблиц;
локализация.
чисто технических критериев выбора, важную роль играют также деловые критерии, например опыт
внедрения и надежность продавца.
4) Разработка собственной системы. Отметим недостатки такого подхода по сравнению с покупкой готовой
системы:



трудозатраты на создание собственной интегрированной системы огромны и составляют сотни и тысячи
человеко-лет, стоимость разработки соизмерима со стоимостью готовой системы (а часто значительно
превышает ее): такие продукты должны реализовываться большими коллективами программистов;
использование готовой системы менее рискованно, чем разработка собственной;
готовая система внедряется поэтапно и поэтому частично может быть доступна в рабочем режиме гораздо
быстрее, чем собственная.
Техническое проектирование. На данном этапе на основе системного проекта и принятых решений по
информатизации осуществляется проектирование системы. Фактически здесь дается ответ на вопрос «Как (каким
образом) мы будем строить систему, чтобы она удовлетворяла предъявленным к ней требованиям?». Этот этап
разделяется на два подэтапа:
проектирование архитектуры системы, включающее разработку структуры и интерфейсов ее компонент
(автоматизированных рабочих мест), согласование функций и технических требований к компонентам,
определение информационных потоков между основными компонентами, связей между ними и внешними
объектами;
2) детальное проектирование, включающее разработку спецификаций каждой компоненты, разработку
требований к тестам и плана интеграции компонент, а также построение моделей иерархии программных
модулей и межмодульных взаимодействий и проектирование внутренней структуры модулей.
При этом происходит расширение системного проекта:
1)



за счет его уточнения;
за счет построения моделей автоматизированных рабочих мест, включающих подсхемы информационной
модели и функциональные модели, ориентированные на эти подсхемы вплоть до идентификации
конкретных сущностей информационной модели;
за счет построения моделей межмодульных и внутримодульных взаимодействий.
Тема 5.
Проектирование корпоративных информационных систем
Современные корпоративные автоматизированные информационные системы (КАИС или АИС) относятся к числу
наиболее сложных систем, создаваемых человеком. Методы и средства их создания развиваются быстрыми темпами в
качественном и количественном отношениях, вовлекая в русло системной интеграции все большее число специалистов.
Переход к информационной экономике и формирование рынка информационных ресурсов, широкое использование
современных информационных технологий предполагают наличие серьезной нормативно-правовой и методической
поддержки экономических информационных систем, учитывающей интеграцию и совместимость информационных
процессов, персональную ориентацию проектных решений, автоматизацию проектирования, гарантии качества
проектных и информационных технологий и услуг. При проектировании АИС должны быть обеспечены:
•
эффективная поддержка принятия проектных решений на основе действующих нормативно-правовых
документов, стандартов, методик и технологий проектирования;
•
высокий уровень проектных решений, реализующий необходимый срок эксплуатации до модернизации и
реконструкции системы;
• дружественные и технологичные проектные интерфейсы с разработчиками, учитывающие возможности обучения
и повышения квалификации;
•
эффективные средства управления проектированием и обеспечения информационной безопасности проектных
работ.
Системный подход к разработке АИС, учитывающий требования внутренней и внешней совместимости, наличия
возможностей их интеграции, модернизации, реконструкции и развития, предполагает обязательную проработку и
единообразие методического обеспечения АИС и их компонентов на различных стадиях проектирования. Регламентация
вопросов методического обеспечения АИС на различных стадиях проектного цикла позволяет скоординировать и
гармонизировать требования к АИС по их нормативно-правовому и информационному взаимодействию, что позволит
создать
предпосылки
к
организации
единого
информационного
пространства
государства,
формированию
цивилизованного рынка информационных ресурсов, перехода к информационной экономике.
В узкоспециальном плане системное проектирование рассматривается как набор методов и организационная
дисциплина, предназначенные для проектирования информационных систем определенных видов. Пояснение предмета
представлено перечислением основных классов тех ИС, к проектированию которых относятся рассматриваемые методы:
• общеуправленческие ИС (MIS — management information system и EIS — executive information system);
• специализированные ИС по отраслям производства, например банковские учетные и управленческие системы,
управление дискретным промышленным производством, системы профилактической и режимной деятельности органов
МВД и др.;
• специализированные ИС по видам деятельности, например управление работой склада, система маркетинговых
исследований, аналитическая система для работы на фондовом рынке и др.;
• адаптивные универсальные ИС по применяемым методам обработки информации, например электронный архив,
корпоративная система управления процессом выполнения офисных работ, система статистических расчетов и др.
Таким образом, в ИС включаются и те типы систем, которые еще десять — пятнадцать лет назад рассматривались
как отдельные от ИС: диалоговые системы решения задач и системы управления различными технологическими
процессами (как ИС не рассматриваются системы прямого управления механизмами и агрегатами, но возможно их
использование как компонентов ИС).
Для проектирования специализированной ИС или адаптации универсальной ИС к требованиям и нуждам
конкретного заказчика применяется во многом общий набор методов и технологий. Этот набор составляет основу
дисциплины «системного проектирования» — того специфического знания, которое вместе со знаниями о конкретном
предприятии и его технологиях используется при построении любой автоматизированной информационной системы.
Этапы проектирования информационных систем. К проектированию АИС непосредственное отношение имеют
два направления деятельности:
1)
собственно проектирование АИС конкретных предприятий (отраслей) на базе готовых программных и
аппаратных компонентов с помощью специальных инструментальных средств разработки;
2) проектирование упомянутых компонентов АИС и инструментальных средств, ориентированных на многократное
применение при разработке многих конкретных информационных систем.
Сущность первого направления может быть выражена словами системная интеграция. Разработчик АИС должен
быть специалистом в области системотехники, хорошо знать международные стандарты, состояние и тенденции
развития информационных технологий и программных продуктов, владеть инструментальными средствами разработки
приложений (CASE-средствами) и быть готовым к восприятию и анализу автоматизируемых прикладных процессов в
сотрудничестве со специалистами соответствующей предметной области. Существует ряд фирм, специализирующихся
на разработке проектов АИС (например, Price Waterhouse, Jet Info, Consistent Software и др.).
Второе направление в большей мере относится к области разработки математического и программного обеспечения
для реализации функций АИС — моделей, методов, алгоритмов, программ на базе знания системотехники, методов
анализа и синтеза проектных решений, технологий программирования, операционных систем и т.п. В каждом классе
АИС (АСУ, САПР, ГИС и т.д.) имеются фирмы, специализирующиеся на разработке программных (а иногда и
программно-аппаратных) систем. Каждая из них рекламирует свою технологию создания АИС и придерживается
стратегии либо тотального поставщика, либо открытости и расширения системы приложениями и дополнениями
третьих фирм.
Как собственно АИС, так и компоненты АИС являются сложными системами, и при их проектировании
целесообразно использовать нисходящий стиль блочно-иерархического проектирования, включающего ряд уровней и
этапов.
Верхний уровень проектирования АИС часто называют концептуальным проектированием. Концептуальное
проектирование выполняется в процессе предпроектных исследований, формулировки технического предложения,
разработки эскизного проекта.
Предпроектные исследования проводятся путем анализа (обследования) деятельности предприятии (компании,
учреждения, офиса), на котором создается или модернизируется АИС. Перед обследованием формируются и в процессе
его проведения уточняются цели обследования — определение возможностей и ресурсов для повышения эффективности
функционирования предприятия на основе автоматизации процессов управления, проектирования, документооборота.
Содержание обследования — выявление структуры предприятия, выполняемых функций, информационных потоков,
имеющихся опыта и средств автоматизации. Обследование проводится системными аналитиками (системными
интеграторами) совместно с представителями организации-заказчика.
На основе анализа результатов обследования разрабатывается исходная концепция АИС, включающая предложения
по изменению структуры предприятия, взаимодействия подразделений, по выбору базовых программно-аппаратных
средств, предложения должны учитывать прогноз развития предприятия. В отношении аппаратных средств, и особенно
программного обеспечения, такой выбор чаще всего есть выбор фирмы — поставщика необходимых средств (или по
крайней мере базового ПО), так как правильная совместная работа программ разных фирм достигается с большим
трудом.
В концепции может быть предложено несколько вариантов выбора. При анализе выясняются возможности покрытия
автоматизируемых функций имеющимися программными продуктами и, следовательно, объемы работ по разработке
прикладного ПО. Подобный анализ необходим для предварительной оценки временных и материальных затрат на
автоматизацию. Учет ресурсных ограничений позволяет уточнить достижимые масштабы автоматизации, выполнить
разделение создания АИС на работы первой, второй и т.д. очереди.
Результаты анализа — техническое предложение и бизнес-план создания АИС — представляются заказчику для
окончательного согласования.
Как на этапе обследования, так и на последующих этапах целесообразно придерживаться определенной дисциплины
фиксации и представления получаемых результатов, основанной на той или иной методике формализации
спецификаций Формализация нужна для однозначного понимания исполнителями и заказчиком требований,
ограничений и принимаемых решений.
При концептуальном проектировании применяют ряд спецификаций, среди которых центральное место занимают
модели преобразования, хранения и передачи информации. Модели, полученные в процессе обследования предприятия,
— модели его функционирования. В процессе разработки АИС модели, как правило, претерпевают существенные
изменения, и в окончательном виде они рассматриваются уже как модели проектируемой АИС.
Различают функциональные, информационные, поведенческие и структурные модели. Функциональная модель
системы описывает совокупность выполняемых системой функций. Информационные модели отражают структуры
данных — их состав и взаимосвязи. Поведенческие модели описывают информационные процессы (динамику
функционирования), в них фигурируют такие категории, как состояние системы, событие, переход из одного состояния
в другое, условия перехода, последовательность событий. Структурные модели характеризуют морфологию системы (ее
построение) — состав подсистем, их взаимосвязи.
Содержание последующих этапов нисходящего проектирования — определение перечней приобретаемого
оборудования и готовых программных продуктов, построение системной среды, детальное инфологическое
проектирование баз данных и их первоначального наполнения, разработка собственного прикладного ПО, которая в
свою очередь делится на ряд этапов нисходящего проектирования.
Особое место в ряду проектных задач занимает разработка проекта корпоративной телекоммуникационной сети,
поскольку техническое обеспечение АИС имеет сетевую структуру.
Если территориально АИС располагается в одном здании или в нескольких близкорасположенных зданиях, то
корпоративная сеть может быть выполнена в виде совокупности нескольких локальных подсетей типа Ethernet или
Token Ring, связанных опорной сетью типа FDDI, ATM или высокоскоростными вариантами Ethernet. Кроме выбора
типов подсетей, связных протоколов и коммутационного оборудования приходится решать задачи распределения узлов
по подсетям, выделения серверов, выбора сетевого ПО, определения способа управления данными в выбранной схеме
распределенных вычислений и т.п.
Если АИС располагается в удаленных друг от друга пунктах, в частности, расположенных в разных городах, то
решается вопрос об аренде каналов связи для корпоративной сети, поскольку альтернативный вариант использования
выделенного канала в большинстве случаев оказывается неприемлемым из-за высокой цены. Естественно, что при этом
прежде всего рассматривается возможность использования услуг Internet. Возникающие при этом проблемы связаны с
обеспечением информационной безопасности и надежности доставки сообщений.
Ход развития информационных технологий позволяет сделать вывод, что мировое сообщество переходит на
технологии создания открытых информационных систем.
Инструментальные средства проектирования и разработки информационных систем
В современных информационных технологиях важное место отводится инструментальным средствам и средам
разработки АИС, в частности системам разработки и сопровождения их программного обеспечения. Эти технологии и
среды образуют системы, называемые CASE-системами.
Используется двоякое толкование аббревиатуры CASE, соответствующее двум направлениям использования CASE-
систем. Первое из них — Computer Aided Software Engineering — переводится как автоматизированное проектирование
программного обеспечения, соответствующие CASE-системы часто называют инструментальными средами разработки
ПО (RAD —- Rapid Application Development). Второе — Computer Aided System Engineering — подчеркивает
направленность
на
поддержку
концептуального
проектирования
сложных
систем,
преимущественно
слабоструктурированных. Такие CASE-системы часто называют системами BPR (Business Process Reengineering).
Среди систем RAD различают интегрированные комплексы инструментальных средств для автоматизации всех
этапов жизненного цикла ПО (такие системы называют Workbench) и специализированные инструментальные средства
для выполнения отдельных функций (Tools). Средства CASE по своему функциональному назначению принадлежат к
одной из следующих групп:
1) средства программирования;
2) средства управления программным проектом;
3) средства верификации (анализа) программ;
4) средства документирования.
Проектирование ПО с помощью CASE-систем. Оно включает несколько этапов. Начальный этап —
предварительное изучение проблемы. Результат представляется в виде исходной диаграммы потоков данных и
согласуется с заказчиком. На следующем этапе выполняется детализация ограничений и функций программной
системы, и полученная логическая модель вновь согласуется с заказчиком. Далее разрабатывается физическая модель,
т.е. определяется модульная структура программы, выполняется инфологическое проектирование базы данных,
детализируются граф-схемы программной системы и ее модулей, проектируется пользовательский интерфейс.
Примерами широко известных инструментальных сред RAD служат платформа .NET, Delphi, PowerBuilder
соответственно фирм Microsoft, Borland, PowerSoft. Применение инструментальных сред существенно сокращает объем
ручной работы программистов (особенно при разработке интерфейсных частей программ).
В средах быстрой разработки приложений обычно реализуется способ программирования, называемый управлением
событиями. При этом достигается автоматическое создание каркасов программ, существенно сокращается объем
ручного кодирования, особенно при разработке интерфейсных частей программ.
Создание сред RAD для сетевого программирования требует решения ряда дополнительных проблем,
обусловливаемых много-платформенностью, обилием применяемых форматов данных и т.п. Решение этих проблем, а
также устранение некоторых особенностей языка C++, усложняющих программирование, достигнуто в языке
программирования Java и платформе .NET.
Спецификации моделей информационных систем. Важное значение в процессе разработки информационных
систем имеют средства спецификации их проектов. Средства спецификации в значительной мере определяют суть
методов CASE.
Существует ряд способов представления моделей. Практически все способы функциональных спецификаций имеют
следующие общие черты:
• модель имеет иерархическую структуру, представляемую в виде диаграмм нескольких уровней;
• элементарной частью диаграммы каждого уровня является конструкция «вход — функция — выход»;
• необходимая дополнительная информация содержится в файлах поясняющего текста.
В большинстве случаев функциональные диаграммы — это диаграммы потоков данных (DFD — Data Flow Diagram).
В DFD блоки (прямоугольники) соответствуют функциям, дуги — входным и выходным потокам данных. Поясняющий
текст дается в виде «словарей данных», в которых указываются компонентный состав потоков данных, число
повторений циклов и т.п. Для описания структуры информационных потоков можно использовать нотацию Бэкуса —
Наура.
Разработка DFD начинается с построения диаграммы верхнего уровня, отражающей связи программной системы,
представленной в виде единого процесса, с внешней средой. Декомпозиция процесса проводится до уровня, где
фигурируют элементарные процессы, которые могут быть представлены одностраничными описаниями алгоритмов
(мини-спецификациями) на языке программирования.
Для описания информационных моделей наибольшее распространение получили диаграммы «сущность — связь»
(ERD — Entity-Relations Diagrams), фигурирующие, например, в методике IDEF1X.
Поведенческие модели описывают процессы обработки информации. В системах CASE их представляют в виде
граф-схем,
диаграмм
перехода
состояний,
таблиц
решений,
псевдокодов
(языков
спецификаций),
языков
программирования, в том числе языков четвертого поколения (4GL).
В граф-схемах блоки, как и в DFD, используют для задания процессов обработки, но дуги имеют иной смысл: они
описывают последовательность передач управления (вместе со специальными блоками управления).
В диаграммах перехода состояний узлы соответствуют состояниям моделируемой системы, дуги — переходам из
состояния в состояние, атрибуты дуг — условиям перехода и инициируемым при их выполнении действиям. Очевидно,
что, как и в других, конечно-автоматных моделях, кроме графической формы представления диаграмм перехода
состояний, можно использовать также табличные формы. Так, при изоморфном представлении с помощью таблиц
перехода состояний каждому переходу соответствует строка таблицы, в которой указываются исходное состояние,
условие перехода, инициируемое при этом действие и новое состояние после перехода.
Близкий по своему характеру способ описания процессов основан на таблицах (или деревьях) решений. Каждый
столбец таблицы решений соответствует определенному сочетанию условий, при выполнении которых осуществляются
действия, указанные в нижерасположенных клетках столбца.
В псевдокодах алгоритмы записываются с помощью как средств некоторого языка программирования
(преимущественно для управляющих операторов), так и естественного языка (для выражения содержания
вычислительных блоков). Используются конструкции (операторы) следования (условные) цикла.
Языки четвертого поколения направлены на описание программ как совокупностей заранее разработанных
программных модулей, поэтому возможно соответствие одной команды языка 4GL значительному фрагменту
программы на языке 3GL. Примерами языков 4GL могут служить Informix-4GL, JAM, NewEra.
Мини-спецификации процессов могут быть выражены с помощью псевдокодов (языков спецификаций), визуальных
языков проектирования или языков программирования.
Технологии проектирования информационных систем
Взаимосвязанная совокупность методик концептуального проектирования IDEF (Integrated Definition) разработана по
программе Integrated Computer-Aided Manufacturing в США. В этой совокупности имеются методики функционального,
информационного и поведенческого моделирования и проектирования, в ее состав в настоящее время входят IDEFметодики, отмеченные в табл. 5.1.
Таблица 5.1 IDEF-методики
Название
Назначение
IDEFO
Функциональное моделирование (Function Modeling Method)
IDEF1 и IDEF1X
Информационное моделирование (Information and Data Modeling Methods)
IDEF2
Поведенческое моделирование (Simulation Modeling Method)
IDEF3
Моделирование процессов (Process Flow and Object State Description Capture Method)
IDEF4
Объектно-ориентированное проектирование (Object-Oriented Design Method)
IDEF5
Систематизации объектов приложения (Ontology Description Capture Method)
IDEF6
Использование рационального опыта проектирования (Design Rationale Capture Method)
IDEF8
Взаимодействие человека и системы (Human-System Interaction Design)
IDEF9
Учет условий и ограничений (Business Constraint Discovery)
IDEF14
Моделирование вычислительных сетей (Network Design)
Методики функционального моделирования. Наиболее известная методика функционального моделирования
сложных систем — методика SADT (Structured Analysis and Design Technique), предложенная в 1973 г. Россом и
впоследствии ставшая основой стандарта IDEFO. Эта методика рекомендуется для начальных стадий проектирования
сложных информационных систем управления, производства, бизнеса, включающих людей, оборудование, программное
обеспечение.
Разработка SADT-модели начинается с формулировки вопросов, на которые модель должна давать ответы, т.е.
формулируется цель моделирования. Далее выполняются этапы:
1) сбор информации. Источниками информации могут быть документы, наблюдение, анкетирование и т.п.
Существуют специальные методики выбора экспертов и анкетирования;
2) создание модели. Используется нисходящий стиль: сначала разрабатываются верхние уровни, затем нижние;
3) рецензирование модели. Реализуется в итерационной процедуре рассылки модели на отзыв и ее доработки по
замечаниям рецензентов, в завершение собирается согласительное совещание.
Поведенческое моделирование сложных систем используется для определения динамики функционирования
сложных систем. В его основе лежат модели и методы имитационного моделирования систем массового обслуживания,
сети
Петри,
возможно
применение моделей конечных
автоматов,
описывающих
поведение системы как
последовательности смены состояний.
Поведенческие аспекты приложений отражает методика IDEF3. Если методика IDEFO связана с функциональными
аспектами и позволяет отвечать на вопрос «что делает система?», то в IDEF3 детализируются и конкретизируются
IDEF0-функции, IDEF3-мо-дель отвечает на вопрос «как система это делает?». В IDEF3 входят два типа описаний:
1) процессно-ориентированные в виде последовательности операций;
2)
объектно-ориентированные, представляемые диаграммами перехода состояний, характерными для конечно-
автоматных моделей, в этих диаграммах имеются средства для изображения состояний системы, активностей, переходов
из состояния в состояние и условий перехода.
Системы информационного моделирования реализуют методики инфологического проектирования баз данных.
Широко используются язык и методика IDEF1X создания информационных моделей приложений, развивающая более
раннюю методику IDEF1. Кроме того, развитые коммерческие СУБД, как правило, имеют в своем составе совокупность
CASE-средств проектирования приложений.
Этапы разработки информационной модели. В IDEF1X имеется ясный графический язык для описания объектов
и отношений в приложениях. Этот язык есть язык диаграмм «сущность — связь» (ER). Разработка информационной
модели по IDEF1X выполняется в несколько этапов.
Этап 1. Выясняются цели проекта, составляется план сбора информации. Обычно исходные положения для
информационной модели вытекают из IDEF0-модели.
Этап 2. Выявление и определение сущностей. Это неформальная процедура.
Этап 3. Выявление и определение основных отношений. Результат представляется или графически в виде ERдиаграмм, или в виде матрицы отношений, элемент которой Аij= 1, если имеется связь между сущностями i и j, иначе Аij
= 0, транзитивные связи не указываются.
Этап 4. Детализация неспецифических отношений, определение ключевых атрибутов, установление внешних
ключей. Детализация неспецифических отношений заключается в замене связей «многие ко многим» на связи «многие к
одному» и «один ко многим» введением сущности-посредника.
Этап 5. Определение атрибутов и их принадлежности сущностям.
Методика IDEF4 реализует объектно-ориентированное проектирование больших систем. Она предоставляет
пользователю графический язык для изображения классов, диаграмм наследования, таксономии методов.
Методика IDEF5 направлена на представление онтологической информации приложения в удобном для
пользователя виде. Для этого используются символические обозначения (дескрипторы) объектов, их ассоциаций,
ситуаций и схемный язык описания отношений классификации, «часть — целое», перехода и т.п. В методике имеются
правила связывания объектов (термов) в правильные предложения и аксиомы интерпретации термов.
Развитие BPR методик продолжается в США по программе IICЕ (Information Integration for Concurrent Engineering).
Разработаны методики:
• IDEF6, направленная на сохранение рационального опыта проектирования информационных систем, что
способствует предотвращению повторных ошибок;
• IDEF8 для проектирования диалога человека с технической системой;
• IDEF9 для анализа имеющихся условий и ограничений (в том числе физических, юридических, политических) и их
влияния на принимаемые решения в процессе реинжиниринга;
• IDEF14 для представления и анализа данных при проектировании вычислительных сетей на графическом языке с
описанием конфигураций, очередей, сетевых компонентов, требований к надежности и т.п.
Основные положения стандартов IDEF0 и IDEF1X использованы также при создании комплекса стандртов ISO
10303, задающих технологию STEP для представления в компьютерных средах информации, относящейся к
промышленному производству. В свою очередь стандарты STEP, совокупность языков таких, как Express и SGML, а
также стандарты P-LIB и MANDATE составляют основу технологии CALS информационного обеспечения всех этапов
жизненного цикла промышленных изделий.
Технология CALS призвана разрешить проблему согласования содержания и формы представления данных о
промышленной продукции в территориально распределенной сети проектных и производственных узлов на основе
совокупности международных стандартов и телекоммуникационных технологий. Только в этих условиях станет
возможной оптимальная специализация предприятий, распределенное проектирование, минимизация затрат на освоение
и эксплуатацию созданных систем.
Классическое проектирование информационных систем
Как классическое рассматривается проектирование ИС для достаточно стабильных условий, что явно или неявно
предполагалось в 70-е и в первой половине 80-х годов XX в. Представительность соответствующих технологий,
ориентация на наиболее массовую часть ИС, наличие не только теоретических оснований, но и промышленных методик
и стандартов, использование этих методик в течение десятилетий — именно это позволяет называть описываемые
методы классическими. Методы проектирования таких ИС в 80-х годах были хорошо описаны и в зарубежной, и в
отечественной литературе разных направлений: методические монографии, стандарты (ГОСТы, ANSI, ISO), учебники.
Рассматриваемые методы в разной терминологии под различными названиями предусматривали последовательную
организацию работ. За 20 лет и в разных «школах» проектирования разбиение работ на стадии и их названия менялись.
Кроме того, наиболее разумно организованные методики и стандарты избегали жестко однозначного приписывания
работ к конкретным стадиям. Вместе с тем при возможности неоднократного включения некоей работы в общую схему
прагматически устойчиво выделялись следующие проектные стадии (некоторые названия соответствующих этапов
работ и (или) соответствующих документов в англоязычной литературе):
• запуск: организация основания для деятельности и запуск работ: приказ и(или) договор о разработке
автоматизированной системы, задание на выполнение работ (proposal for the development, agreement, mobilization);
• обследование: предпроектное обследование, общий анализ ситуации на предприятии, разработка общего
обоснования целесообразности создания ИС (feasibility stady, scope analysis, strategy stady and planning, requirement
definition);
• концепция, ТЗ: исследования требований предприятия и пользователей, выработка рекомендаций по разработке
ИС, разработка ТЗ на проектирование ИС в целом и частных ТЗ по подсистемам (strategy planning, analysis, requirement
specification, function description);
• эскизный проект: разработка архитектуры будущей ИС в рамках эскизного проекта (detailed analysis, high level
design);
• опытный вариант ИС: разработка упрощенного варианта, пилотного проекта будущей ИС (pilot-project, test
development);
• опытное использование пилот-проекта ИС, разработка исправлений и дополнений к ТЗ (test, corrected requirement
specification);
• ТП: разработка технического проекта ИС (detailed analysis and design, test development);
• РП: разработка рабочей документации проекта (development, test, system implementation);
• ввод в действие: по-другому — «внедрение» ИС (deployment, put into operation).
Одно из использовавшихся в западной литературе названий такой схемы организации работ — это «водопадная или
каскадная модель» (waterfall model). Схема обязана была включать итерационные процедуры уточнения требований к
системе и рассмотрения вариантов проектных решений. Все же эти процедуры и целые этапы работ носили в основном
последовательный характер, а, кроме того, предметом была проектируемая ИС целиком, в целостном ее представлении.
Положительные факторы применения данной схемы наблюдались в следующем:
• на каждой стадии формировался законченный, отвечающий критериям полноты и согласованности набор
проектной, а затем и пользовательской документации, охватывающий все предусмотренные стандартами виды
обеспечения ИС: организационное, методическое, информационное, программное, аппаратное и др.;
• выполняемые в логичной последовательности этапы работ достаточно очевидным образом позволяли планировать
сроки завершения всех работ и соответствующие затраты. Структура ИС, как она формируется в ходе разработки,
представлена такой схемой табл. 5.2.
Таблица 5.2 Структура формирования информационной системы
Виды обеспечения информационной системы
Стадии
проекта
организационное
Запуск
+-
Обследование
+-
методическое информационное
+-
+-
программное аппаратное
Концепция ТЗ
+-
+-
+-
Эскизный
+-
+-
+-
+-
ТП
+-
++
+
+-
+-
РП
++
++
++
++
+
Ввод в действие
++
++
++
++
++
проект
Символами «+», « + - » и « + +» показаны примерные оценки доли наличия каждого компонента на
каждой стадии
Эти стадии работ стали также называть частями «проектного цикла» системы. Такое название возникло потому, что
в этапы включалось много итерационных процедур уточнения требований к системе и вариантов проектных решений.
Жизненный цикл самой системы существенно сложнее и больше. Он может включать в себя произвольное число циклов
уточнения, изменения и дополнения уже принятых и реализованных проектных решений. В этих циклах происходило и
развитие ИС, и модернизация ее компонентов.
Отрицательные факторы применения описанной схемы проектирования.
Недостаток 1 (опоздание). Чаще всего в качестве основного недостатка называлось существенное запаздывание с
получением результатов, имевшее несколько аспектов:
• согласование результатов с пользователем производилось только в точках, планируемых после завершения каждого
этапа работ; это приводило к тому, что разработчики делали не ту ИС, которую хотели заказчик или тем более
пользователи, а ту, которую представили себе проектировщики-аналитики, затем — программисты;
• модели автоматизируемого объекта, отвечающие критериям внутренней согласованности и полноты, для маломальски крупного проекта ИС устаревали (т.е. переставали отвечать реальным внешним требованиям) вскоре после их
утверждения, а иногда и одновременно с ним; это относится и к функциональной модели, и к информационной, и к
проектам интерфейса пользователя, и к инструкциям персоналу;
• попытки довести до внедрения проект, выполняющийся в такой манере, заставляли или искажать требования к ИС,
или превышать сроки и смету разработки, или делать и то и другое.
Недостаток 2 (бесполезность). Существовал и явным образом описывался в литературе еще один крупный
недостаток разрабатываемых ИС, относящийся скорее к практике разработки ИС, чем к теории. И в зарубежной, и в
отечественной литературе практики и ведущие аналитики оценивали проектирование ИС как очень часто ведущее к
примитивной автоматизации (по сути — механизации) существующих производственных действий работников.
Как альтернатива такому подходу требовалось получение с помощью ИС качественно новых результатов,
позволяющих осуществлять оптимальное управление производством в целом, динамически менять управление
производственными процессами на предприятии, принимать лучшие управленческие решения, встраивать контроль
качества и рациональное управление внутрь производственных процессов, использовать их самими производственными
коллективами.
Такой подход рекомендовалось осуществлять всегда, но он встречал скрытое и явное сопротивление работников на
предприятиях. Это было и является в настоящее время проблемой во всех странах. Такой подход полностью отвечал бы
определениям кибернетики по Н. Винеру, но был очень редко достижим.
Вместе с тем в начале 80-х годов XX в. большинству проектировщиков ИС казалось, что имеющиеся модельные и
организационные методы проектирования, а также поддерживающие их программные средства составляют законченную
дисциплину, которая может совершенствоваться, но уже позволяет, в общем, успешно планировать и осуществлять
разработки больших ИС.
Более развитые организационные подходы. Они развивались, в первую очередь, хотя и не только, для
уменьшения первого недостатка: «опозданий».
1. Схема непрерывной разработки. Примером может служить подход, который руководители больших проектов IBM
в 70-х — 80-х годах прошлого столетия называли «Продолжающейся разработкой». Характеризующей особенностью
такого подхода стал непрерывный процесс разработки и развития большой ИС с планируемыми точками передачи в
эксплуатацию новых версий и новых функциональных блоков (подсистем, задач) и встроенными в процесс постоянно
осуществляемыми процедурами экспертизы качества, работоспособности и др.
Схема проектного цикла при продолжающемся проектировании, совпадающая с циклом жизни системы, приведена
на рис. 5.1. В верхней части того же рисунка представлена более распространенная схема.
Большое внимание уделялось организации процесса проектирования. Выделим положение, в соответствии с
которым встроенные в процесс экспертизы должны были, в частности, служить тем средством обратной связи,
основываясь на котором можно было бы и получать подтверждение пользователя и совершенствовать сам процесс
разработки.
Рис. 5.1. Схема непрерывной разработки
Существенно, что процесс системного проектирования начал получать спиральный характер, при котором каждый
следующий виток служил развитию спроектированной на предыдущих витках и уже функционирующей системы. Один
виток спирали при этом представлял собой законченный проектный цикл по типу каскадной схемы.
2. Схема циклической разработки. В 80-х годах использование принципа продолженной разработки для ускоренного
поочередного внедрения отдельных программных комплексов — прикладных или общесистемных — стало развиваться
в разных направлениях и получило несколько ходовых жаргонных названий, например «быстрое прототипирование»
(rapid prototyping approach или fast-track). В проектный цикл для этого дополнительно включались такие стадии:
• разработка макета-прототипа фрагмента будущей ИС (rapid prototyping) совместно с будущим пользователем;
• опробование макета-прототипа фрагмента будущей ИС, доработка прототипа до работающего фрагмента ИС
(feedback, improved prototype design and development).
Однако применение таких методов наряду с быстрым эффектом давало снижение управляемости проектом в целом и
стыкуемости различных фрагментов ИС
Недостаток 3 и 4 (жесткость и закрытость). Рассмотренные усовершенствованные схемы проектирования
претендовали и сейчас часто претендуют на получение и ввод в действие компонентов формально целостной в
традиционном смысле ИС и последующей их стыковки в такую ИС.
Для планирования формально целостной ИС рекомендовалось на стадии обследования вначале определять
укрупненные функции системы, затем детализировать их. По мере реализации фрагментов ИС предполагалось
использовать детальные описания функций соответствующего фрагмента.
Такая организация проектирования названа проектированием «сверху вниз» (не путать с одноименным стилем
программирования). Упоминаемая функциональная иерархия — очень важный признак рассматриваемых подходов. Изза определяющего влияния на процессы и результаты проектирования ИС иерархических структур для представления
функций и данных в ИС применявшиеся подходы получили общее условное название — «структурное
проектирование». Привычность и доступность иерархических моделей были привлекательным фактором.
Не только жесткость моделей, но и использование фирменных («патентованных») архитектур используемых
компьютеров, операционных систем и систем управления базами данных приводило к отрицательным результатам при
возникновении неизбежной необходимости развития ИС. Эти недостатки получили оценку как недостатки закрытых
систем: закрытые ИС было трудно или очень дорого развивать, очень дорого или практически невозможно стыковать с
другими системами.
Одно из популярных в то время представлений архитектуры такой закрытой ИС показано на рис. 5.2, где:
1) компьютер конкретного типа (конкретной фирмы-производителя);
2) конкретная операционная система для данного типа компьютера;
3) СУБД для 1 и 2;
4) прикладные программы для 2 и 3: пакетные (диалоговые) для фиксированных функций или языки
нерегламентированных запросов;
5) пользователь-оператор, обученный именно для 2, 3 и 4;
6) конечный пользователь: обучен и снабжен инструкциями для работы именно с 4 и 5.
Рис. 5.2. Модель-луковица закрытой ИС
Недостаток 5 (типовые оргструктуры). Потенциальная возможность и необходимость применения оргмероприятий
для построения ИС (или АСУ), меняющих оргструктуры повышения эффективности работы предприятия в
отечественных условиях, практически не использовалась. Для каждого предприятия, его отделения или отдела
существовали так называемые типовые оргштатные структуры, расписания и положения. Для того чтобы произвести
изменение в этой области, чаще всего нужно было решение соответствующего министерства, поэтому в большинстве
случаев оргструктура оставалась неизменной, а ИС повторяла те функции, которые ранее выполнялись вручную.
Прежде чем перейти к характеристикам методов, соответствующих тем или иным стадиям классического системного
проектирования, опишем наблюдавшуюся в тот же период ситуацию с организацией совершенствования управления
производством, которая по большому счету всегда должна была быть целью проектирования ИС.
Классические методы проектирования. Конец 70-х — начало 80-х годов — это время становления технологии
интегрированных баз данных как одной из головных технологий в проектировании ИС. Был разработан и вошел в
практику большой набор теоретически обоснованных методов: проектирование концептуальных и логических схем БД,
организация физической среды хранения данных, планирование путей доступа к данным и др. Развивались методы
проектирования функций: от методов формальной спецификации функций до структурного программирования и первых
непроцедурных языков программирования четвертого поколения (4GL). Анализ функций (задач) предприятия также
служил основой и в проектировании БД. Появились CASE-системы, ориентированные на формализацию
информационных и функциональных требований к ИС и предназначенные для формального описания и бригадной
разработки больших программных комплексов.
В конце 70-х — середине 80-х годов XX в. и в нашей стране большое количество разработчиков успешно применяли
методы разработки ИС и БД не только на интуитивно-ремесленном уровне, но и как элементы сложившейся
дисциплины. Укажем на наиболее популярные из них, применявшиеся на первых стадиях проектирования.
Обследование, общий анализ ситуации на предприятии и разработка общего обоснования целесообразности
создания ИС (feasibility stady, scope analysis, strategy stady and planning):
общий системный и ситуационный анализ текущего состояния и целей предприятия, его масштабов, возможности,
стоимости и способов разработки ИС, решающей задачи, способствующие достижению целей предприятия;
использование методов, структурного анализа, ГОСТов на разработку АСУ и САПР.
«Концепция, ТЗ»: исследования требований предприятия и пользователей, выработка вариантов и рекомендаций по
разработке ИС, разработка ТЗ на проектирование ИС в целом и ЧТЗ по подсистемам (strategy stady, analysis, requirement
specification):
1) анализ критических факторов успеха и риска с использованием системного и ситуационного анализа;
2) обследование предприятия методами анализа документов, интервью, прямых наблюдений, хронометража и др.
(большое количество методик: от SADT Д. Росса до ГОСТа по предпроектным исследованиям при разработке САПР);
3) определение соответствия существующей оргструктуры, функций, документов и других целям предприятия;
4) проектирование более целесообразных и учитывающих создаваемую ИС оргструктуры, набора и иерархии
функций («задач»), видов документов и правил документооборота, вычленение предметных БД, определение
взаимосвязей между ними;
5) разработка предложений по изменениям на предприятии, затрагивающим оргструктуру, документооборот и др.;
6) построение недетализированных моделей БД и функций ИС (с использованием диаграмм данных Ч. Бахмана,
модификаций ER-модели П. Чена, функциональных моделей по стандартам IDEFO, по методике HIPO или др.);
7) сбор и описание детальных требований к составу данных и алгоритмам реализации функций (см., например,
популярную [16], а также [58], [61] и требования серий ГОСТ24 и ГОСТ36).
«Эскизный проект»: разработка архитектуры будущей ИС в рамках эскизного проекта (detailed analysis, high level
design):
1) построение нормализованной реляционной или сетевой модели БД (методы получения нормальных форм Бойса
— Кодда, четвертых и пятых нормальных форм, использование предложений комитета CODASYL);
2) определение принципов организации в ИС интерфейсов конечного пользователя (принципы эргономики, как,
впрочем, и влияние компьютерной моды, переход от командного интерфейса к диалоговым режимам «вопрос — ответ»,
«управление через меню»);
3)
определение
модульной
иерархии
(верхние
уровни)
программного
обеспечения
ИС
(модульное
программирование, метод HIPO);
4)
определение принципов организации аппаратного компьютерного комплекса, на базе которого должна
функционировать ИС (расчеты физических параметров ИС: объемов БД, временных характеристик отдельных операций
доступа к данным, целых функций и режимов в целом, организации компьютерных сетей, см. также [58]);
5) определение основных оргмероприятий по созданию и вводу в действие ИС;
6) определение совокупности требований к приемке будущей ИС;
7) определение сроков, состава работ и их стоимости для последующих работ по ИС.
Существовал набор методов, применявшихся и на других этапах.
Использование классических методов проектирования ИС сегодня. Все эти методы остались в арсенале
разработчиков и в настоящее время. Однако они и соответствующие инструменты начинают совсем по иному
применяться в условиях BPR и открытой архитектуры ИС. Кроме того, теперь они сочетаются с новыми методами,
позволяющими достичь большей гибкости и процесса разработки, и самой ИС, причем за меньшее время. В отношении
собственно классических методов изменения в первую очередь касаются качества их компьютерной поддержки, т.е.
применения новых ИТ для поддержки классических методов.
Некоторые из усовершенствований в компьютерной поддержке проектирования ИС начиная со второй половины 80х годов:
1) широкое применение графических диалоговых интерфейсов (диаграммы структур данных, иерархий функций,
потоков данных и др.);
2) использование компьютерных сетей и работа с распределенными базами данных для поддержки кооперативной
групповой разработки (использование общих словарей-справочников данных, теперь — «репозитариев»);
3) постепенное расширение использования понятийных моделей и методов объектного моделирования.
Конечно, новые ИТ заставили включать в классические методики соответствующие новые функции. Как пример это
относится к средствам динамического моделирования архитектур клиент-сервер и систем с распределенными базами
данных. Однако включение отдельных новых функций не меняло подхода в целом и не устраняло описанных выше
недостатков.
Тем не менее, несмотря на то что у большинства отечественных разработчиков возможности использовать,
например, распределенные БД отсутствовали из-за плохих линий связи и низкой надежности компьютеров, изменения в
ИТ происходили во всем мире, влияли на методы проектирования и стандарты и проникали в отечественные разработки.
Качественные изменения в информационных технологиях
В 80-х годах прошлого столетия произошел целый ряд качественных изменений в ИТ. Некоторые из них
осознавались постепенно, другие, как феномен персональных вычислений, входили в жизнь гораздо более
революционным путем. Кратко рассмотрим, как эти изменения все более ограничивали применение классических
методов системного проектирования, требуя новых подходов в разработке чисто компьютерных компонентов ИС, а
также как эти изменения помогали появлению ВPR. Три качественных скачка в информационных технологиях. Наконец,
к концу 80-х — началу 90-х годов XX в. во всем мире не только разработчиками, но и пользователями были осознаны
три действительно революционных феномена. Они стали все шире входить в отечественную практику, качественно
меняя деятельность компьютеризованных предприятий:
1) феномен персональных вычислений, основанный на постоянной доступности работнику возможностей ЭВМ, в
первую очередь — на использовании персональных компьютеров. Феномен состоит в том, что во многих видах
информационных,
проектных
и
управленческих
работ
исчезла
необходимость
в
работниках-исполнителях
(машинистках, чертежниках, делопроизводителях и др.), являющихся посредниками между постановкой задачи и ее
решением;
2) феномен кооперативных технологий, состоящий в компьютерной поддержке совместной согласованной работы
группы работников над одним проектом. Этот феномен возник на основе суммы методов, обеспечивающих управление
доступом членов группы к разным частям проекта, управление версиями и редакциями проектной документации и
согласованным выполнением работ в последовательной процедуре работ, управление параллельным конструированием
и др.;
3) феномен компьютерных коммуникаций, заключающийся в резком увеличении возможностей обмена любой
информацией. Он возник, в частности, на основе стандартизованных протоколов обмена данными прикладного уровня в
локальных и глобальных сетях, что позволило исключить необходимость передачи бумажных документов для
получения согласия или содержательных замечаний, ненужные переезды для проведения совещаний, обеспечить
постоянную готовность работника получить и отослать сообщение или информативные записи данных вне зависимости
от места его географического расположения и др.
Оценка их влияния на производственную деятельность и оргструктуры, разработка соответствующих методик
производились не только за рубежом, но и отечественными специалистами, хотя тогда у нас время реального
применения этих методов еще не настало.
Понятийная модель предметной области. Открытые архитектуры стимулируют использование готовых покупных
компонентов ИС разных разработчиков. Необходимость строить ИС на основе набора «покупных» приложений разных
поставщиков, причем набора, состав которого надо уметь изменить в нужное время, привела к практической
невозможности использовать классические структурные технологии проектирования интегрированных систем.
Например, замена программного комплекса бухгалтерской или складской подсистемы на более развитый, но других
разработчиков, приводит к тому, что меняется структура БД и набор действий с данными. Даже если по большому счету
в новом приложении будут выполняться те же функции, но, например, быстрее и в более удачной компоновке, а
информация хранится всего лишь в виде более детальных сведений и т.п., то информационные и функциональные
модели могут отличаться друг от друга практически во всех деталях! Из-за этого старые способы построения
интегрированных моделей стали отказывать все чаще и чаще.
В силу этого проектирование ИС из покупных компонентов на формальном уровне может оказаться близким к
хаотичной самодеятельной разработке полностью несогласованных программ для решения частных задач предприятия,
т.е. к так называемому позадачному подходу, с попытками последующего соединения таких задач в целостную систему.
С другой стороны, постепенно осуществлялись попытки преодолеть разрыв между формальными требованиями к
проектированию целостных больших ИС с интегрированными базами данных и реальной динамикой жизни, требующей
постоянной смены то одного, то другого программного комплекса. (Часто такие попытки помещались критиками в одну
графу с позадачным подходом и отвергались.) Постепенно и практикам, и теоретикам, и рискованным новаторам, и
критикам-консерваторам становилось ясно, что обе крайности неприменимы: ни вульгарный позадачный подход, ни
попытки разработки полностью законченных больших ИС с заранее полностью спроектированной интегрированной
базой данных.
Эти и другие предпосылки были основанием того, что единственным достаточно стабильным интегрирующим
элементом современной ИС может являться не информационная и тем более не функциональная модель предприятия, а
только понятийная модель предметной области, да и то при условии ее постоянного пересмотра и обновления.
Пассивные понятийные модели такого прикладного рода строились и представлялись в виде терминологических
словарей и тезаурусов понятий. Такие словари строились как часть обеспечения ИС и содержали описания элементов
информационных, функциональных, организационных и других моделей для ИС. Однако практически все
использование таких моделей для проектирования и развития ИС приходилось и приходится делать вручную.
Активные понятийные модели разрабатывались не только для хранения описаний используемых понятий и связей
между ними. Ставились цели динамически формировать новые суждения, определять тождество или сходство понятий,
производить их интерпретацию вычислительного характера. К таким моделям относятся разные представления
семантических сетей. Однако создание технологически полных механизмов такого рода оказалось очень сложной
задачей. Для непосредственного использования в промышленных разработках ИС активные понятийные модели до
последнего времени были непригодны.
В настоящее время слияние средств представления знаний с технологией обобщенных объектов и стандартизацией в
области объектно-ориентированных представлений реально ведет на следующий, качественно новый уровень в
технологии системного проектирования [35].
Описанные выше, а также некоторые другие новые информационные технологии дали возможность принципиально
пересмотреть технику как собственно проектирования ИС, так и управления процессами проектирования, но влияние
этих новых технологий оказалось более широким.
Классические методы проектирования информационных систем, несмотря на известные достоинства, всегда имели
сильные отрицательные стороны. Разработка ИС была слабо связана с реальным повышением эффективности
производства. Развитие открытой архитектуры, феномены персональных вычислений, кооперативных технологий и
компьютерных коммуникаций дали новый толчок к росту уровня постоянной изменчивости требований в услугах ИС.
Новые информационные технологии увеличили возможности классических методов проектирования ИС за счет новых
способов их компьютерной поддержки, а также за счет включения в них новых функций для проектирования
распределенных систем и начала использования элементов понятийных моделей. Однако жесткость классических
методов стала барьером на пути их дальнейшего применения. Можно ожидать, что новое системное проектирование в
качестве интегрирующего слоя будет использовать пассивные, а в ближайшем будущем и активные понятийные модели.
Новые информационные технологии не только дали возможность радикального изменения методов проектирования
ИС, но и реальные возможности радикального изменения самих целей разработки информационных систем.
1. Тема 6.
Менеджмент создания информационной системы
Менеджмент создания информационной системы зависит от подходов
применяемых при проектировании. В настоящее время всё большее распространение
получает объектно-ориентированный подход к анализу и проектированию экономических
информационных систем. Данный подход к проектированию реализуется в рамках
унифицированного процесса. Название унифицированный процесс (Unified Process)
подходит к общему определению процесса: набор действий, который выполняет команда
для преобразования набора требований клиента в экономическую информационную
систему. Однако унифицированный процесс — это еще и настраиваемая структура
проекта, которую пользователи могут изменить, добавляя или устраняя виды
деятельности, основываясь на индивидуальных потребностях и доступных ресурсах
проекта.
Одной из реализаций унифицированного процесса является унифицированный
процесс компании Rational (Rational Unified Process— RUP), который является примером
специализированной версии унифицированного процесса, образованной за счет
добавления элементов в настраиваемую структуру.
Унифицированный процесс широко использует унифицированный язык
моделирования (Unified Modeling Language— UML). Основой UML является модель,
способная в контексте процесса разработки информационной системы упростить
реальность, что помогает команде проекта понять наиболее сложные аспекты создание
информационной системы.
Язык UML был создан для того, чтобы помочь участникам разработки
информационных систем строить модели, способные охватить систему, определить ее
структуру и поведение, а также создать систему и письменно зафиксировать решения,
принятые в ходе работы. Большинство заданий, которые определяет унифицированный
процесс, используют UML и одну или несколько моделей.
Процесс, управляемый прецедентами
Прецедент— это последовательность действий, которые выполняются одним или
более актором (некто или нечто вне системы) либо самой системой и приводят к
результату, возвращаемому для одного или нескольких акторов. Одним из ключевых
аспектов унифицированного процесса можно назвать использование прецедентов в
качестве движущей силы разработки. Характеризуя процесс как управляемый
прецедентами, мы имеем в виду, что команда проекта использует прецеденты для
выполнения всей разработки — от начального сбора информации и обсуждения
требований до написания кода.
Прецеденты очень удобны для уточнения требований, анализа, разработки и
реализации, и тому есть ряд причин.
• Прецеденты выражаются с точки зрения пользователей системы, что более
удобно для клиентов, так как они видят отражение своих требований в тексте описания
прецедентов. Ведь клиенту иногда трудно увидеть воплощение собственных условий в
контексте требований.
• Прецеденты пишутся на родном языке пользователей. Если прецедент описан
хорошо, то читатель понимает его на интуитивном уровне.
• Прецеденты предоставляют гораздо больше возможностей для понимания
действительных требований к системе, чем стандартные документы с требованиями,
которые обычно написаны неясно, многословно и противоречиво. В идеале организаторам
стоит рассматривать прецеденты как обязательные контракты между клиентами и
разработчиками, где согласуются все детали относительно будущей системы.
• Прецеденты позволяют достичь высокого уровня оперативного контроля
трансформации требований в модели в процессе разработки. Если команда разработки
постоянно сверяет выполненную работу с описанием прецедентов, она всегда будет в
курсе требований клиента.
• Прецеденты позволяют легко преобразовать требования на задачи, которые
можно распределить между командами, упростив таким образом организацию
выполнения проекта.
Процесс, основанный на архитектуре
В контексте информационной системы термин архитектура имеет разные
значения. Все зависит от того, кого вы спросите. В идеологии UML архитектура
представляет собой базовую организацию системы. Аспектами архитектуры являются
статические элементы, динамические элементы, их совместная работа, а также общий
архитектурный стиль, который определяет организацию системы. Архитектура также
имеет отношение к вопросам производительности, масштабируемости, повторного
использования, экономических и технологических ограничений.
Один из принципов унифицированного процесса состоит в том, что архитектура
разрабатываемой системы является фундаментом, на котором будет базироваться система,
и потому нужно сосредоточить на ней все усилия команды проекта, чтобы придать форму
системе. В то же время архитектура в сочетании с прецедентами должна управлять
исследованием всех аспектов системы. Можно представить архитектуру, как нечто,
отражающее общее видение всех членов команды, необходимое для того, чтобы созданная
система была надежной, гибкой, масштабируемой и рентабельной.
Архитектура в первую очередь определяется терминами представления шести
моделей. Эти представления отражают "архитектурно значимые" элементы моделей; все
представления вместе взятые образуют архитектурное описание. Команда проекта
создает архитектурное описание на ранних стадиях разработки, а затем в ходе всех видов
деятельности, связанных с проектом, расширяет и совершенствует его.
Инструменты и технологии, доступные разработчикам для создания
информационных систем, становятся все более мощными. Программное обеспечение
информационных систем, ориентированное на распределенную обработку данных
становится все более сложным. К тому же внимание клиентов снижается, в то время как
их требования к командам разработчиков становятся все сложнее. В результате этого
программное обеспечение информационных систем становится доступными для
понимания лишь ограниченному кругу высококвалифицированных специалистов.
Описание архитектуры призвано в первую очередь облегчить понимание того, как
строится архитектура системы. Чтобы описание архитектуры могло служить более
глубокому пониманию "полной картины" новой системы, потребуется длительное
тщательное моделирование и повышенное внимание к читабельности связанных диаграмм
UML и вспомогательного текста.
Хорошая архитектура явно определяет отдельные части системы и связующие
звенья между ними. В ней также эффективно используются одна или несколько
архитектурных схем, чтобы обрисовать действия по разработке на разных уровнях. (Среди
хорошо известных архитектурных схем можно назвать тип клиент/сервер, трехуровневый
и N-уровневый типы. В других схемах делается акцент на брокерах объектных запросов
(ORBs); они находятся в центре системы и используют распределенные компоненты и
виртуальные машины наподобие тех, на которых работает Java.) Эффективно используя
это свойство архитектуры, команда проекта может положительно влиять на общий ход
работы.
Один из базовых принципов разработки, основанной на использовании
компонентных объектов, заключается в том, чтобы применять компоненты практически
без изменений в контексте разных разработок. Хорошо сконструированная архитектура
предоставляет надежную основу для компонентов и их постоянного взаимодействия. Это
позволяет командам, разрабатывающим другие системы, определить возможности
повторного использования любого из них или всех вместе. Практический результат этих
действий в том, что, чем меньше времени команда затратит на построение новых
компонентов, тем больше времени она сможет уделить рассмотрению проблем заказчика
и моделированию решений.
Поддержка и совершенствование системы обычно занимает больше времени, чем
первоначальное создание. В то время когда проекты работают в мифическую эру Internet,
когда технологии развиваются все быстрее, а бизнес-модели меняются все чаще, не
остается сомнений в том, что система любого размера и сложности подвергнется
эволюционным изменениям в необходимом масштабе. При наличии надежной
архитектуры можно выделить ряд необходимых контрольных точек и опираться на них
при дальнейшей разработке. Если архитектура построена так, что изменения в одной
части системы почти никогда не будут неблагоприятно влиять на остальные части
системы, существенно повышается возможность членов команды эффективно
развертывать систему.
С одной стороны, прецеденты управляют архитектурой информационной системы,
поскольку они управляют всеми действиями при разработке. А с другой стороны,
архитектура управляет выбором и исследованием прецедентов. Решения, которые
архитекторы принимают относительно промежуточного программного обеспечения,
системного программного обеспечения, унаследованных систем и т.д., оказывают
существенное влияние на выбор прецедентов, на которых будет сосредоточена команда на
разных этапах проекта. Цель состоит в том, чтобы сконцентрировать внимание на тех
прецедентах, которые способствуют разработке хорошей архитектуры, определяющей, в
свою очередь, содержание этих прецедентов и природу работы, необходимой для
построения из них системы.
Унифицированный
процесс
характеризуется
итеративностью
и
инкрементностью природа. Итерация представляет собой мини-проект, результатом
которого является версия системы и, который завершается внешним либо внутренним
выпуском. Считается, что эта версия является улучшенным (инкрементным) вариантом
предыдущей версии, поэтому результат итерации называется инкрементом.
На этапе ранних итераций команда создает начальную архитектуру, которая
предлагает исходные принципы надежной основы; в ходе последующих итераций команда
расширяет свое видение полной архитектуры, что, в свою очередь, влияет практически на
все, а в некоторых случаях абсолютно на все задачи разработки, которые необходимо
выполнить как часть данной итерации. Построение архитектуры по итеративноинкрементному принципу позволяет команде внести основные изменения на ранней
стадии процесса, что принесет меньше убытков, чем при выполнении этого на более
поздних этапах.
Процессы, основанные на водопадном подходе, при котором все требования
должны быть собраны и проанализированы перед началом разработки, сталкиваются с
неизбежной проблемой: требования не остаются неизменными. К тому же заказчики с
трудом представляют себе систему, если все, что у них есть, — это документация.
Унифицированный процесс поддерживает необходимость разбивки системы на
конструкции, каждая из которых представляет собой рабочую версию определенной
значимой части целой системы. Сосредоточив внимание на связанных наборах
прецедентов и эффективно используя прототипы, команда проекта сможет
взаимодействовать с заказчиком на протяжении всей работы, таким образом уменьшая
(часто очень большой) риск, связанный с попытками определить все требования наперед.
Некоторые компания используют принцип "безжалостного установления приоритетов",
согласно которому при работе с изменяющимися требованиями довольно агрессивно
определяются приоритеты, а элементы с низким приоритетом исключаются из
рассмотрения.
Поскольку каждая итерация представляет собой мини-проект, то каждый раз при
создании инкремента системы команда разработчиков в той или иной мере сталкивается
со всеми рисками, связанными с проектом. Когда риск увеличивается, возникают
задержки и среда становится нестабильной, команда может внести необходимые поправки
на уровне одной итерации, а затем распространить их по всей системе. В ходе выполнения
постпрограммы для каждой итерации руководители проекта, прежде чем приступать к
работе над следующей итерацией, могут решить, была ли итерация успешной и подходит
ли данная схема итерации. Цель состоит в том, чтобы изолировать проблемы в пределах
отдельной итерации и решить их в небольшом формате, вместо того чтобы позволить
распространиться на весь проект.
Каждая итерация привносит комбинацию новых свойств и улучшает
функциональность системы. Это позволяет организаторам проекта ограничить его
развитие достижением конкретных целей, а не более абстрактных и общих требований.
Постоянно интегрируя новые инкременты, команда разработчиков получает возможность
также изолировать проблемы, которые итерация может внести в систему, и исправляет их
так, чтобы они не могли нарушить целостности работающей системы. Такое
формирование задания упрощает работу команды, которая может пойти на то, чтобы
отбросить отдельный инкремент и начать все сначала, потому что ход развития проекта
позволяет определить, какую из итераций можно выполнить быстрее.
Каждый вид деятельности команды в ходе итерации, строго определен как
последовательность действий, принадлежащая одному технологическому процессу или
нескольким одновременно. Процесс построен таким образом, чтобы можно было
полагаться на постоянный инструктаж непосредственно в ходе работы как на
альтернативу предварительному всестороннему обучению сотрудников, которые лишь
после его окончания становятся полноценными членами команды. Хорошо определенные
итерации не оставляют места для экспериментов и ошибок, поскольку эти ошибки могут
быть изолированы так, что их влияние на расписание работ и бюджет будет
минимальным. В ходе работы команда может расширить представление о том, что она
пытается разработать, и о связанных с этим рисках, т.е. получить представление о
движущей силе проекта, что, в свою очередь, позволит команде непрерывно вносить
изменения, совершенствуя свою деятельность по выполнению задач.
Наверное, наиболее важное преимущество итеративной и инкрементной
разработки состоит в том, что она позволяет команде сосредоточить усилия на устранении
наиболее опасных моментов в ранний период жизненного цикла. Команда может
организовать итерации так, чтобы постоянно работать над устранением рисков; целью
является максимально возможное снижение риска в ходе каждой итерации, чтобы каждая
новая итерация сопровождалась меньшим количеством рисков (к тому же менее важных),
чем предыдущие.
Предлагаются различные подходы к организации категорий рисков в проектах
разработки программного обеспечения. При обсуждении унифицированного процесса
небесполезным будет описание трех категорий рисков, приведенное ниже.
• Технические риски связаны с различными технологиями, применяемыми в ходе
процесса и с совершенствованием таких свойств, как производительность, а также
читаемость, расширяемость и т.д. Например, если в системе в контексте Common Object
Request Broker Architecture (CORBA — обобщенная архитектура брокера объектных
запросов) использовать технологию Enterprise Java Beans (EJB), команде проекта придется
решить ряд потенциальных технических проблем, для того чтобы система могла
приемлемо работать. Процесс не ориентирован специально на устранение технических
рисков, но команда работает над их устранением на ранних этапах, еще до начала
кодирования.
• Архитектурные риски связаны со способностью архитектуры служить прочным
фундаментом системы, а также быть гибкой и легкоадаптируемой к добавлению новых
свойств в будущих версиях системы. К этой категории также относятся риски, связанные
с такими решениями, как "создание в сравнении с окупаемостью". Процесс устраняет
архитектурные риски при определении видов деятельности, которые включают анализ,
разработку и реализацию архитектуры, а также при определении некоторых других видов
деятельности, в число которых входит постоянное обновление описания архитектуры с
тем, чтобы она могла занять ведущее место в ходе разработки.
• Риск при работе с требованиями — это риск разработать не ту систему, за
которую платят клиенты, ввиду непонимания требований или из-за того, что в процессе
разработки были использованы не те прецеденты. Процесс устраняет этот риск с
помощью видов деятельности, специально предназначенных для того, чтобы упростить
обсуждение и уточнение требований, а также исходного условия, согласно которому
прецеденты управляют всеми аспектами разработки.
Жизненный цикл разработки программного обеспечения информационной системы
может быть представлен в виде ряда циклов. Цикл завершается выпуском версии системы
клиентам.
Каждый цикл унифицированного процесса состоит из четырех фаз. Фаза
представляет собой промежуток времени между двумя вехами, т.е. точками, в которых
менеджеры принимают важные решения относительно продолжения разработки и в
случае положительного решения определяют границы проекта, бюджет и расписание.
На рис. 4.1 показаны фаза и вехи унифицированного процесса. Как видите, каждая
фаза содержит одну или более итераций.
Рис. 1.1. Фазы и вехи
Исследование – анализ и определение требований
Основной целью фазы исследования является доказательство жизнеспособности
предложенной системы.
Задачи, которые ставит перед командой разработчиков эта фаза, включают
следующее:
• определение области действия системы (т.е. какие данные можно ввести и что из
этого получится);
• определение потенциальной архитектуры, которая состоит из начальных версий
шести разных моделей;
• выделение критических рисков и определение, когда и как можно их устранить;
• начало оценки экономической рентабельности проекта, которая основывается на
начальных оценках стоимости, затраченных усилий, графика и качества продукта.
Веха, связанная с фазой исследований, называется цели жизненного цикла. Вот
основные признаки того, что эти цели достигнуты:
• основные организаторы проекта достигли единого мнения относительно области
действия предложенной системы;
• потенциальная архитектура явно устраняет ряд критических требований высокого
уровня;
• бизнес-план проекта достаточно обоснован, чтобы оправдать дальнейшую
продолжительную разработку.
Уточнение планов – проектирование системы
Основной целью фазы уточнения планов является подтверждение возможности
разработать систему с учетом финансовых, временных. и других видов ограничений, с
которыми сталкивается проект разработки.
В ходе фазы уточнения планов команда разработчиков выполняет следующие
задачи:
• охват необходимого большинства функциональных требований;
• расширение потенциальной архитектуры до уровня полной базовой линии
архитектуры, которая представляет собой внутреннюю версию системы, основанную на
описании архитектуры;
• устранение значительных рисков по мере их возникновения;
• завершение бизнес-плана проекта и подготовка плана проекта, достаточно
подробного для осуществления следующей фазы (построение).
Базовая линия архитектуры состоит из расширенных версий шести моделей,
созданных в ходе фазы исследований.
Фаза уточнения планов завершается вехой архитектуры жизненного цикла. По
следующим признакам можно определить, что проект достиг этой вехи:
• эта модель прецедентов охватывает большинство функциональных требований
новой системы;
• базовая линия архитектуры представляет собой небольшую и компактную
систему, которая может служить надежной основой для непрерывной разработки;
• составлен успешный бизнес-план, и команда разработчиков имеет в наличии план
проекта, который описывает развитие фазы построения.
Построение
Основной целью фазы построения является разработка системы, способной
функционировать в испытательных условиях, повторяющих условия заказчика.
В ходе фазы построения команда разработчиков выполняет задания, включающие
итеративное и инкрементное построение системы, достигает уверенности в том, что
систему можно реализовать с сохранением жизнеспособности.
Фаза построения завершается вехой первоначальной работоспособности. Проект
считается достигшим этой вехи, если у клиентов на руках оказывается более-менее
работоспособная система.
Развертывание - внедрение
Основной целью этой фазы является передача полностью работоспособной
системы пользователям.
В ходе фазы развертывания команда разработчиков сосредоточена на исправлении
недостатков и на внесении поправок в систему с тем, чтобы откорректировать ранее не
замеченные изъяны.
Пять технологических процессов
В унифицированном процессе выделяют пять технологических процессов, которые
присутствуют в ходе выполнения всех четырех фаз: управление требованиями, анализ,
проектирование, реализация и тестирование. Каждый технологический процесс
представляет собой последовательность видов деятельности, которые выполняют
исполнители проекта.
Управление требованиями
Основные
виды
деятельности
технологического
процесса
управления
требованиями направлены на построение модели прецедентов, которая охватила бы все
функциональные требования создаваемой экономической информационной системы. Эта
модель помогает организаторам проекта достичь согласия относительно возможностей
системы и условий, которым она должна соответствовать.
Основным принципом этого этапа является необходимость разработки правильной
системы. Это понятие включает сбор требований заказчиков проекта и их обсуждение до
тех пор, пока не станет ясно, что клиенты и команды разработчиков достигли согласия
относительно свойств будущей системы.
Охватить все требования обычно мешает ряд обстоятельств.
• Несмотря на все практические преимущества, клиенты и разработчики
разговаривают на разных языках.
• Часто сложно понять, чего хотят клиенты, они либо не знают, либо думают, что
знают, но не могут выразить свои мысли, либо меняют мнение и противоречат сами себе
• Документы, в которых фиксируются требования, обычно изобилуют
двусмысленностями, избытком информации и внутренними противоречиями.
Технологический процесс управления требованиями определяет задачи, которые
связаны с четырьмя основными целями удовлетворения требований.
Существует три компонента, которые могут помочь организаторам проекта
достичь согласия относительно того, "с чем работает система и что из этого должно
получиться". Это модели предметной области, бизнес-модели и высокоуровневые
диаграммы прецедентов.
Модель предметной области описывает важные понятия, связанные с системой, в
терминах объектов. Команда может использовать модель предметной области, чтобы
помочь всем участникам достичь соглашения в том, какие потребности должны быть
удовлетворены с помощью новой системы.
Модель предметной области охватывает важные предметы реального мира и
понятия, которые принадлежат области проблемы, т.е. определяют проблему, для решения
которой разрабатывается новая система. Эти предметы и понятия представлены в виде
классов, связанных между собой различными отношениями.
В унифицированном процессе термин бизнес-модель относится к двум моделям:
модели бизнес-прецедентов и модели бизнес-объектов.
Модель бизнес-прецедентов состоит из бизнес-прецедентов, которые описывают
производственные процессы, и системных акторов, которые описывают клиентов и
партнеров. Между обычными бизнес-прецедентами, а также обычными и бизнес-акторами
существует непосредственная связь; на самом деле оба вида прецедентов и акторов
присутствуют в диаграммах прецедентов UML.
Бизнес-модель описывает производственные процессы в терминах клиентов, а
также в виде концептуальных и конкретных производственных объектов. Эта модель
может помочь команде разработчиков понять внутренний принцип действия той сферы
бизнеса, для которой разрабатывается система.
Модель бизнес-объектов описывает, как бизнес-прецеденты "реализуются"
командой исполнителей с помощью бизнес-категорий (которые могут быть как
абстрактными понятиями, например счета, так и конкретными предметами, например
бланки). Эта модель также описывает организационные блоки, которые представляют
собой ряд бизнес-категорий. Бизнес-категории и организационные блоки часто
представляют те же виды понятий и предметов, что и классы в модели предметной
области; таким образом, модель бизнес-объектов обычно отображается на диаграммах
классов уровня предметной области.
Глоссарий содержит различные ключевые термины, характерные для системы,
которые используются в других артефактах проекта. Эти термины могут описывать как
конкретные объекты, так и абстрактные понятия. Цель состоит в том, чтобы организаторы
проекта использовали глоссарий, когда потребуется прийти к общему согласию
относительно того, что именно имеется в виду. Глоссарий обычно составляется на
основании модели предметной области, бизнес-модели или их обеих.
Унифицированный процесс определяет прецедент как основную единицу
воплощения функциональных требований. Диаграммы прецедентов описывают
прецеденты и объекты (люди или предметы), которые с ними взаимодействуют. С
помощью построения диаграмм прецедентов, которые отображают определенные в общих
чертах высокоуровневые прецеденты (например, на уровне "краткое изложение
исполнения" или, возможно, на уровень или два ниже), можно довольно быстро понять, в
пределах каких границ моделируется система.
Актор может означать следующее:
• роль, которую может играть пользователь по отношению к системе;
• некий объект (например, другую систему или базу данных), который находится
вне системы.
Имя актора не должно быть именем конкретного человека; наоборот, оно должно
лишь определять роль или ряд ролей, которые человек, внешняя система или часть
разрабатываемой системы играет в отношении одного или более прецедентов. В бизнесмодели акторы в общем соответствуют исполнителям.
Прецедент представляет собой последовательность действий,
которые
выполняет актор над системой для получения определенного результата.
Прецедент должен описывать один из аспектов использования системы, не
учитывая дизайна и реализации. Другими словами, прецедент описывает, что должна
выполнять система, при этом не уточняя, как система будет это выполнять.
Прототипы пользовательского интерфейса помогают разработчикам уточнить
внешний вид системы и понимание того, как она функционирует, с клиентами, а также
понять некоторые их требования.
Пакет UML представляет собой группирование элементов модели. Пакет может
сам состоять из пакетов. Модель прецедентов — это, по существу, пакет пакетов
прецедентов, каждый из которых состоит из акторов и прецедентов.
Частью архитектурного представления является представление модели
прецедентов, которое содержит значимые для архитектуры прецеденты. К ним относятся
прецеденты, которые описывают важные функциональные возможности, воплощают
особенно важные требования, либо и те и другие.
Каждый из представителей заинтересованных сторон наверняка выступит с
несколькими предложениями, касающимися того, какими свойствами должна обладать
система. Список свойств является документом, который содержит определение и краткое
описание этих предложений. Они могут рассматриваться как потенциальные требования.
(С целью планирования и управления для каждого свойства должно быть достаточно
сопроводительной информации, чтобы можно было трезво оценить график и бюджет.)
Команда может использовать список свойств в качестве справочного материала при
решении, как распределить свойства по действительным требованиям, а затем
проработать в ходе определенного цикла или итерации.
Прецеденты определяют последовательности действий, которые актор (некто или
нечто вне системы, взаимодействующее с ней) и система выполняют, чтобы получить
видимый результат. Используя их, можно точно узнать требования клиента, так как
хорошо написанный текст прецедента очень похож на текст из руководства пользователя.
Прецеденты, особенно если их использовать совместно с прототипами пользовательского
интерфейса, также оказывают серьезную поддержку при обсуждении требований с
клиентами, так как команда разработчиков использует текст прецедентов, чтобы избежать
двусмысленностей, исключить предположения и четко очертить границы наборов
прецедентов, которые будут разработаны в ходе определенной итерации системы. Далее в
главе прецеденты рассматриваются более подробно; кроме того, речь идет о том, как
обнаружить акторов и прецеденты, а также как написать хороший текст прецедента.
Нефункциональные требования связаны с вопросами производительности,
безопасности, расширяемости и надежности. Вместе с определенными прецедентами они
имеют исключительное значение при формировании архитектуры. При выполнении
различных видов деятельности, определенных в технологическом процессе управления
требованиями, команда разработчиков может преобразовать эти требования в модели
предметной области. Использование таких компонентов UML, как ограничение (условие,
которое должно выполняться) и модель прецедентов, в качестве дополнительной
информации, связанной с индивидуальными прецедентами или группами прецедентов,
также помогает охватить эти требования.
Диаграмма классов в UML — наиболее действенный способ в полной мере
представить содержание модели предметной области.
Дополнительное требование еще называют нефункциональным требованием. К
этому виду требований относятся те, которые имеют отношение к таким задачам, как
производительность, безопасность и возможность поддержки, или к ограничениям,
налагаемым на систему извне, например тем, которые включают в себя регулирующие
факторы. Дополнительное требование обычно не соответствует определенному
прецеденту; для его воплощения используется несколько прецедентов.
В технологическом процессе управления требованиями принимают участие
следующие исполнители, которые играют ключевые роли. Следует помнить, что
исполнитель в этом контексте является логической ролью, а не физическим лицом.
Системный аналитик акцентирует внимание на процессах извлечения требований
и моделировании, а также связанных с ними прецедентах. Это включает следующее:
• управление разработкой модели предметной области и бизнес-модели;
• поиск акторов и прецедентов;
• гарантия полноты и непротиворечивости модели прецедентов в целом.
Системный аналитик также несет основную ответственность за составление
глоссария.
Спецификатор прецедентов составляет подробные описания основного и особых
потоков событий для одного или более прецедентов.
Разработчик пользовательского интерфейса работает над визуальным
представлением тех элементов пользовательского интерфейса, которые будут
использовать один или несколько акторов. Для этого обычно сначала разрабатывают
прототип пользовательского интерфейса.
В технологическом процессе управления требованиями архитектор распределяет
в соответствии с приоритетами данный набор прецедентов и заносит архитектурно
значимые прецеденты в описание архитектуры.
Модель прецедентов служит также базой для остальной работы по разработке
системы. На рис. 4.2 показано, какое влияние имеет модель прецедентов на другие пять
моделей.
Рис. 4.2. Шесть основных моделей унифицированного процесса
Анализ
Целью основных видов деятельности технологического процесса анализа является
построение модели анализа, которая помогает разработчикам уточнить и структурировать
функциональные требования, охватываемые моделью прецедентов. Эта модель содержит
реализации прецедентов, которые легче использовать в проектировании и реализации, чем
сами прецеденты.
На этапе технологического процесса анализа основная цель команды
разработчиков состоит в том, чтобы понять требования заказчиков и опираться на них при
установке целей для проектирования и реализации. Первым результатом этого процесса
будет модель анализа, которая предназначена для того, чтобы помочь команде достичь
таких целей, как совместное использование ресурсов, удобство сопровождения,
устойчивость и повторное использование.
Модель анализа представляет собой улучшенную и расширенную модель
прецедентов. Суть этого усовершенствования можно кратко выразить следующим
образом.
• Даже самое скрупулезное моделирование прецедентов наверняка имеет
недоработки в виде недостаточно точно написанного текста и выпущенных из виду
альтернативных потоков событий. Полный анализ модели прецедентов должен устранить
эти упущения.
• Анализ позволит команде разработчиков обратиться к решению таких задач, как
распределение объектов, взаимосовместимость и производительность; как правило, на
начальном этапе моделирования прецедентов этим не занимаются.
• В унифицированном процессе анализ представляет собой часть проекта, в
которой акцент начинает смещаться от нужд заказчиков к потребностям разработчиков,
направленным на то, чтобы разработать систему правильно. Если в ходе
технологического процесса управления требованиями на всех этапах нужно
консультироваться с заказчиками (или, по крайней мере, они должны быть
представлены), то в ходе технологического процесса анализа заказчики привлекаются к
работе, только если возникнет необходимость обсудить требования.
Построение
Основные виды деятельности технологического процесса проектирования
направлены на построение модели проектирования, которая описывает физическую
реализацию прецедентов из модели прецедентов, а также содержание модели анализа.
Модель проектирования служит абстракцией модели реализации.
В технологическом процессе проектирования важное место занимает модель
развертывания, которая определяет физическую организацию системы в терминах
вычислительных узлов.
Основной целью технологического процесса проектирования можно назвать
разработку проекта системы, на который команда сможет опираться, переходя к этапу
реализации. Результатом выполнения этого процесса является создание модели
проектирования и модели развертывания. Модель проектирования воплощает в себе
первичные решения, принятые командой разработчиков в отношении распределения
объектов, взаимосовместимости, баз данных, пользовательского интерфейса, транзакций и
т.д. Модель развертывания определяет территориальное распределение различных
компонентов оборудования, на котором будет разработана система.
Модель проектирования и модель развертывания, взятые вместе, представляют
собой усовершенствованную и расширенную модель анализа. Суть этого
усовершенствования и расширения выражается в следующем.
• Для модели анализа характерна высокая степень абстрактности; разработчики при
выполнении анализа уже рассматривали задачи реализации, но не доводили их до
логического завершения. Модель проектирования является, скорее, материальной: в ней
абстрактные понятия, представленные в модели анализа, переводятся в элементы модели,
отражающие будущую реализацию системы (например, определяются сигнатуры
операций в используемом языке программирования).
• Модель проектирования обычно содержит намного больше деталей, чем модель
анализа; в наибольшей степени это касается особенностей совместной работы объектов,
направленной на обеспечение поведения, определенного моделью прецедентов.
• В то время как модель анализа отражает начальные идеи команды в отношении
распределения объектов по ярусам или уровням, модель развертывания предоставляет
окончательные решения, принятые командой по этим вопросам.
Реализация
Целью технологического процесса реализации является построение модели
реализации, которая описывает, как элементы модели проектирования формируют
компоненты, такие, как файлы исходного кода, библиотеки динамической компоновки
(DLL) и EnterpriseJavaBeans (EJB). При этом создается рабочая версия системы, которую
можно предоставить для оценки бета-пользователям. Точкой отсчета этого
технологического процесса служит модель реализации, содержащая исходный код и
исполняемые файлы, которые вместе формируют реализуемую систему. Команда также
работает над расширением модели развертывания, разработка которой была начата в
процессе проектирования.
Модель реализации — это воплощение модели проектирования в реальности.
Каждый элемент этой модели становится частью компонента, т.е. физической и
заменяемой части системы, которая соответствует набору интерфейсов и реализует его.
Точно так же и полная модель развертывания отражает воплощение в реальности
архитектуры, которая развивалась в процессе работы над разными моделями.
Тестирование
Основные виды деятельности технологического процесса тестирования
направлены на построение модели тестирования, которая описывает, как системные тесты
и тесты интеграции будут применяться к рабочим компонентам модели реализации.
Модель также описывает, как команда будет проводить это, и тестирование модулей.
Модель тестирования содержит набор тестовых данных, которые определяются
непосредственно из прецедентов. Тестирование выполняется методом черного ящика с
использованием оригинального текста прецедентов и тестирования реализаций этих
прецедентов, определенных в модели анализа, методом белого ящика. Тестовая модель
также содержит результаты всех уровней тестирования.
Итерации и инкременты
Каждая из фаз унифицированного процесса делится на итерации. Итерация
представляет собой просто мини-проект, который является частью фазы.
Типичная итерация в большей или меньшей степени имеет место во всех пяти
технологических процессах, описанных ранее. Например, итерация на фазе уточнения
сосредоточена на деятельности, связанной с технологическими процессами управления
требованиями и анализа, в то время как итерация в фазе построения скорее задействует
разработку, реализацию и тестирование.
Результатом итерации является инкремент, который представляет собой версию
системы с дополнительными или усовершенствованными функциональными
возможностями по сравнению с предыдущей версией.
На рис. 4.3 отображена суть итеративного и инкрементного подхода к разработке
программного обеспечения.
Рис. 4.3. Итеративная и инкрементная разработка
Используя итеративный и инкрементный подход, команда проекта начинает
процесс разработки с оценки существенных рисков (куда входят риски, связанные с
требованиями, квалификацией, технологией и политикой), а также с попытки
удостовериться, что определенная область действия проекта удовлетворяет всех. Затем
команда выполняет следующее.
1. Определение первой итерации, ориентируясь на самые сложные и критические
риски (другими словами, прежде всего более сложная часть работы).
2. Составление плана итерации с подходящим уровнем детализации.
3. Выполнение соответствующих действий; для унифицированного процесса виды
деятельности связаны с технологическими процессами управления требованиями,
анализа, реализации и тестирования.
4. Разработка постпрограммы для инкремента, который стал результатом итерации.
5. Составление обновленного списка рисков, не учитывая при этом риски, который
были устранены в этом инкременте.
6. Оценка общего плана проекта в соответствии с относительным успехом или
неудачей при выполнении итерации.
7. Переход к следующей итерации.
В ходе итераций (инкремент за инкрементом) строится шесть моделей. В конце
каждой итерации полный набор моделей, которые представляют систему, находится в
определенном состоянии; это базовая линия архитектуры.
Для каждого технологического процесса унифицированного процесса определены
три элемента: артефакты, исполнители и виды деятельности.
Артефакты
В унифицированном процессе артефактом называют любую значимую
внутреннюю или подлежащую сдаче порцию информации, которая играет определенную
роль в разработке системы. К основном артефактам построения относятся модели,
прототипы пользовательского интерфейса и оценка результатов тестирования. Артефакты
управления, такие, как бизнес-план и план проекта, также обсуждаются в контексте пяти
технологических процессов и четырех фаз. Одним из исходных условий
унифицированного процесса является то, что система не считается готовой к сдаче
заказчику, пока все необходимые артефакты (независимо от того, предназначены они для
внутреннего использования или для пользователей) не завершены должным образом.
Исполнители
В унифицированном процессе исполнитель определяется как роль, которую
индивид может исполнять в ходе выполнения проекта. (Основная разница между
понятиями исполнителя и актора в том, что актор находится вне системы и смотрит на нее
снаружи, в то время как исполнитель находится внутри системы и, возможно, смотрит
наружу, а возможно, и нет. К тому же акторы могут воздействовать и использовать
систему, в то время как исполнители являются участниками разработки системы.)
Исполнители создают артефакты как индивидуально, так и в составе подкоманд
или команд. Единственное, что нужно запомнить: один человек в ходе процесса может
выполнить больше действий, чем исполнитель. Например, аналитик может найти
прецеденты и написать к ним текст.
Виды деятельности
Каждый технологический процесс включает несколько видов деятельности.
В контексте технологического процесса вид деятельности можно определить как
задачу, которую выполняет исполнитель, чтобы создать артефакт. Виды деятельности,
охватывают широкий диапазон, включая как высокоуровневое исследование идей и
интересующих клиента моментов (построение модели предметной области), так и
кропотливую работу, связанную с физической системой (реализация класса).
Тема 7.
Стандарты управления производством
Исторически, методология Enterprise Requirement Planning (ERP), то есть планирование ресурсов предприятия,
является результатом последовательного развития, начавшегося с концепции Material Resource Planning (MRP),
обеспечивавшей планирование потребностей предприятий в материалах. Преимущества, даваемые MRP, состоят в
минимизации издержек, связанных со складскими запасами сырья, комплектующих, полуфабрикатов и прочего, а также
с аналогичными запасами, находящимися на различных участках непосредственно в производстве.
В основе этой концепции лежит понятие Bill Of Material (BOM), то есть спецификации изделия, которая показывает
зависимость внутреннего для предприятия спроса на сырье, комплектующие, полуфабрикаты и т.д. от плана выпуска
(бюджета реализации) готовой продукции. При этом очень важную роль играет фактор времени, поскольку
несвоевременная доставка материалов может привести к срыву планов выпуска готовой продукции. Для того чтобы
учитывать временную зависимость производственных процессов, информационной системе, поддерживающей
реализацию концепции MRP на предприятии, «необходимо знать» технологию выпуска продукции (технологическую
цепочку), то есть последовательность технологических операций и их продолжительность.
На основании плана выпуска продукции, BOM и технологической цепочки в MRP – системе осуществляется расчет
потребностей в материалах в зависимости от конкретных сроков выполнения тех или иных технологических операций.
Однако у методологии MRP есть серьезный недостаток. При расчете потребности в материалах не
учитываются загрузка и амортизация производственных мощностей, стоимость рабочей силы, потребляемой
энергии и т.д. Поэтому в качестве логического развития MRP была разработана концепция Manufacturing Resource
Planning (планирование производственных ресурсов), сокращенно называемая MRP II. В рамках MRP II можно уже
планировать все производственные ресурсы предприятия: сырье, материалы, оборудование, людские ресурсы, все виды
потребляемой энергии и пр.
Далее концепция MRP II развивалась в соответствии с тенденциями изменения рынка и порождаемыми ими новыми
потребностями в управлении предприятиями. К MRP II постепенно добавлялись возможности по учету и управлению
другими затратами предприятия. Так появилась концепция ERP, называемая иногда также Enterprise-wide Resource
Planning (планированием ресурсов в масштабе предприятия). В основе методологии ERP лежит принцип единого
хранилища данных (repository), содержащего
всю деловую информацию, накопленную организацией в процессе
ведения бизнеса, включая финансовую информацию, данные, связанные с производством, управлением персоналом, или
любые другие сведения. Это устраняет необходимость в передаче данных от одной информационной системы к другой и
создает дополнительные возможности для анализа, моделирования и планирования. Кроме того, любая часть
информации, которой располагает данная организация, становится одновременно доступной для всех работников,
обладающих соответствующими полномочиями.
Начиная с середины 90-х годов, концепция ERP стала очень популярной в производственном секторе, поскольку ее
использование для планирования ресурсов позволило существенно сократить время выпуска продукции, снизить
уровень товарно- материальных запасов, а также улучшить обратную связь с потребителем при одновременном
сокращении административного аппарата. Методология ERP позволила объединить информацию обо всех ресурсах
предприятия
добавляя,
таким
MRP II возможности управление заказами, поставками, финансами и т.д.
образом,
к
Итак:
MRP (Material Requirement Planning) – это планирование потребности в материалах;
MRP II (Manufacturing Resource Planning) – это планирование производственных ресурсов;
ERP (Enterprise Resource Planning) – это планирование ресурсов всего предприятия.
Стандарты MRP/ERP поддерживаются Американским обществом по контролю за производственными запасами
APICS (American Production and Inventory Control Society).
MRP/ERP – это набор проверенных на практике разумных принципов, моделей и процедур управления и контроля,
предназначенных для повышения показателей экономической деятельности предприятия.
Так, изданный APICS в 1989 г. стандарт «MRP II Standard System», содержит 16 групп функций производственно сбытовой системы:
2. - Планирование продаж и производства (Sales and Operation Planning);
3. - Управление спросом (Demand Management);
4. - Составление плана производства (Master Production Scheduling);
5. - Планирование материальных потребностей (MRP - Material Requirement Planning);
6. Спецификация продуктов (Bill of Materials);
7. Управление запасами (Inventory Transaction Subsystem);
8. - Управление плановыми поставками (Scheduled Receipts Subsystem);
9. - Управление на уровне производственного цеха (Shop Flow Control);
10. - Планирование производственных мощностей (CRP – Capacity Requirement Planning);
11. - Контроль входа/выхода рабочих потоков (Input/output control);
12. - Материально техническое снабжение (Purchasing);
13. - Планирование ресурсов для распределения (DRP – Distribution Resource Planning);
14. - Планирование и контроль производственных операций (Tooling Planning and Control);
15. - Управление финансами (Financial Planning);
16. - Моделирование для производственной программы (Simulation);
17. - Оценка результатов деятельности (Performance Measurement).
С накоплением опыта моделирования производственных и непроизводственных бизнес -процессов эти понятия
постоянно уточняются, постепенно охватывая все больше функций. Развитие стандарта MRP/ERP проиллюстрировано в
Таблице 1.
Таблица 1. Историческая справка (Gartner Group)
Годы
Обозначение
1945
«30 glorieuses»
Характеристика
Принципы организации производства, заложенные
Тейлором (F.W.Tayle – H.Ford).
1965
MRP 0
Планирование
потребностей
в
материалах
(O.Wight- J.Orlicky), расчет потребностей нетто.
1975
MRP I
Планирование
потребностей в материалах
по
замкнутому циклу (Cloosed Loop Material Requirment
Planning),
включая
составление
производственной
программы и контроль ее исполнения на цеховом
уровне (Miller – Sprague).
1980
MRP II
Планирование
основе
данных,
производственных
полученных
от
ресурсов
поставщиков
на
и
потребителей, ведение прогнозирования, планирования
и контроля за производством.
1985
MRP II +
Появление идеологии JIT (Just in Time - точно в
срок), комбинация с элементами «Канбан системы»
(S.Shingo – M.Ohno). Добавление системы OPT
(E.Goldratt) – оптимизация «узких мест».
1990
ERP
Планирование ресурсов предприятия. Добавление
DRP (Distribution Resource Planning - планирование
ресурсов для распределения) и FRP (Financial Resource
Planning финансовое планирование).
1996 Extend
ERP
Supply Chain – управление цепочками поставок,
позволяющей направлять и контролировать движение
материальных
и
информационных
потоков
от
поставщика к потребителю.
2001
ERP II
Customers
Relationship
Management
(CRM)
–
управление отношениями с покупателями
Современная структура модели MRP/ERP
Сегодня модель MRP/ERP включает в себя следующие подсистемы, которые часто
называют также блоками или сериями:
1.
2.
3.
4.
5.
6.
7.
8.
- управление запасами;
- управление снабжением;
- управление сбытом;
- управление производством;
- планирование;
- управление сервисным обслуживанием;
- управление цепочками поставок;
- управление финансами.
Остановимся кратко на базовой функциональности, поддерживаемой каждой из подсистем.
Управление запасами
Эта подсистема обеспечивает реализацию следующих функций:
1) Inventory Control – мониторинг запасов;
2) Physical Inventory – регулирование и инвентаризация складских остатков.
При решении задач управления запасами - производится обработка и корректировка всей информации о приходе,
движении и расходе сырья и материалов, промежуточной продукции и готовых изделий; учет запасов по складским
ячейкам, выбор индивидуальных стратегий контроля, пополнения и списания запасов по каждой позиции номенклатуры
сырья и материалов, и т.д. Учитывается нормативная и текущая фактическая стоимость запасов, а также отслеживается
прохождение отдельных партий запасов и серий изготавливаемой продукции.
Управления снабжением
Подсистема реализует следующие функции:
1) Purchase Orders - заказы на закупку;
2) Supplier Schedules - график поставок;
3) MRP - планирование потребности в материалах, понимаемое как управление заявками
на закупку.
Управление сбытом
Базовыми функциями этой подсистемы являются:
1) Sales Quotations - квотирование продаж;
2) Sales Orders / Invoices - заказы на продажу (счета фактуры);
3) Customer Schedules - график продаж потребителям;
4) Configured Products - конфигурирование продуктов;
5) Sales Analysis - анализ продаж;
6) Distributed Resource Planning (DRP) - управления ресурсами распределения.
Управления производством
В этой подсистеме реализуются следующие функции, соответствующие различными типам производственных
процессов:
1) Product Structures - спецификация изделий, определяющая, какие материалы и комплектующие используются в
производимом изделии;
2) Routings/Work Centers - операции/центры переработки, включает в себя описание цехов, участков, рабочих мест;
3) Formula/Process - технологические процессы производства продукции с маршрутизацией по рабочим центрам для
объемного (процессного) производства.
4) Work Orders – наряд-задание (сменное задание) на производство работ для позаказного и мелкосерийного
производства;
5) Shop Floor Control - управление трудозатратами (диспетчирование);
6) Repetitive - поточное производство (для серийного и массового производства).
7) Quality Management - управление качеством, то есть описание различных проверок изделий во время
производственного процесса.
Планирование
В модели MRP/ERP предусматривается сквозное планирование, согласование и оперативная корректировка планов и
действий снабженческих, производственных и сбытовых звеньев предприятия.
Подсистема планирования реализует следующие функции:
1. Product Line Planning (PLP) – финансовое планирование товарно-номенклатурных групп (ТНГ);
2. Master Scheduling Planning (MSP) – главный календарный график или объемно календарное планирование;
3. Distribution Resource Planning (DRP) – планирование распределения ресурсов (RCP);
4. Materials Requirements Planning (MRP) – планирование потребности материалов;
5. Capacity Requirements Planning (CRP)– планирование потребления мощностей.
Эту функциональность можно условно отнеси к трем уровням планирования, отражающим иерархию планов в ERPмодели.
Управление сервисным обслуживанием
Эта подсистема активно используется компаниями, которые не только производят и продают свою продукцию, как,
например, производители продовольствия, но и обеспечивают послепродажное техническое обслуживание и
техническую поддержку своей продукции. Подсистема обеспечивается полный спектр необходимых функций: от
создания графика технического обслуживания, заказа комплектующих, учета контрактов на обслуживание и
формирования счетов до учета прибыли, получаемой от послепродажного обслуживания.
Управление цепочками поставок
Эта подсистема предназначена для обеспечения эффективного управления материальными и соответствующими им
информационными потоками: от поставщика через производство к потребителю. Реализованная в подсистеме идеология
«управления глобальными цепочками поставок» дает промышленным предприятиям возможность представлять свою
деятельность в виде так называемых эффективных цепочек логистики: от поставщиков сырья и комплектующих до
продажи готовых изделий конечному потребителю. При этом обеспечиваются широкие возможности управления
транснациональными
компаниями,
координации
распределенного
между
многими
дочерними
компаниями
производства.
Управление финансами
В соответствии с идеологией MRP/ERP эта подсистема полностью интегрирована со всеми остальными и позволяет
оперативно получать информацию о финансовых потоках, связанных с потоками материальными, о текущем
финансовом состоянии компании, и помогает находить оптимальные финансово – экономические решения. Сквозное
управление материальными потоками находит свое отражение в управлении финансовыми потоками (движении
денежных средств).
В подсистеме реализована функциональность:
1. General Ledger – главная бухгалтерская книга, предназначенная для отражения финансовых транзакций и ведения
бухгалтерского учета;
2. Multiple Currency – мультивалютность, для ведения учета в разных валютах;
3. Accounts Receivable - дебиторская задолженность;
4. Accounts Payable - кредиторская задолженность;
5. Payroll - заработная плата;
6. Cost Management - управление себестоимостью;
7. Cash Management - управление платежами;
8. Fixed Assets - учет основных средств.
Модель MRP/ERP реализована в ряде информационных систем (ERP –систем) корпоративного уровня. Согласно
статистическим данным, полученным при анализе использования ERP-систем в США, результатом внедрения таких
систем на предприятиях является сокращение объемов запасов в среднем на 17 %, уменьшение затрат за закупку сырья и
материалов на 7 %, повышение рентабельность производства в среднем на 30% и качества выпускаемой продукции на
60%.
2.3.
Реализация
стандартов
управления
в
корпоративных
информационных системах (КИС)
Приобретая и внедряя корпоративную информационную систему, предприятия получают вместе с ней и
соответствующую технологию управления. Построение современной системы корпоративного управления - процесс
длительный, сложный и трудоемкий. И если предприятие решается на проект внедрения КИС, то перед ним встает
проблема выбора системы, наиболее соответствующей его роду деятельности, исторически сложившейся структуре и
методам управления. Ясно, что в процессе внедрения, который во многом представляет собой перманентный консалтинг
и последующую реорганизацию действующих бизнес – процессов, и структура и система управления предприятие будут
серьезно видоизменены. Однако это изменение не должно быть ломкой рациональных устоев, которые, собственно, и
позволяли предприятию существовать весь период, предшествующий внедрению КИС. Новая информационная система
должна нести в себе позитивный заряд перемен, многократно усиливающих традиционно сильные стороны
предприятия, оптимизирующих его структуру и методы управления, ликвидирующих устаревшие, тормозящие бизнес
формы и методы руководства.
Западные аналитики различают два вида корпоративных информационных систем:
Business Management Systems (BMS) – системы управления бизнесом;
Enterprise Recourse Planning (ERP) – системы планирования ресурсов предприятия.
В свою очередь, BMS – системы разбиваются на три группы. В первую из них входят простые системы,
предназначенные для автоматизации малых предприятий.
Системы этой группы рассчитаны на выполнение весьма ограниченного числа стандартных бизнес - процессов и
представляют собой «коробочный продукт». Как правило, они работают на одном рабочем месте или в небольших сетях
из 4 – 8 компьютеров. За рубежом такие системы называют «Low End PC». Отечественным примером системы такого
уровня является «1С Бухгалтерия».
Ко второй группе, называемой «Middle PC», относят системы, отличающейся большей глубиной и широтой охвата
функций. Они нуждаются в настройке, которую в большинстве случаев осуществляют специалисты фирмыразработчика. В такой системе могут быть описаны десятки бизнес - процессов. В основном данные системы
автоматизируют бухгалтерский и/или складской учет, как например «1C Предприятие».
Следующая группа систем под названием «High End PC» рассчитана на работу большого числа пользователей.
Такие системы могут применяться на средних предприятиях, не предъявляющих высоких требований к
функциональности и гибкости системы управления. В системах этой группы можно встретить описание уже сотен
бизнес - процессов. В большинстве случаев они могут работать в среде Windows NT или UNIX. Среди российских
программных продуктов к данному классу относятся “Галактика”, “NS2000”; среди западных – «Concorde XAL».
Высший уровень иерархии занимают системы, которые обеспечивают планирование и управление всеми ресурсами
предприятия и строятся на основании MRP/ERP модели, то есть ERP-системы. В них содержится описание тысяч
бизнес - процессов. Такие системы могут иметь до 100 тысяч настраиваемых параметров, позволяющих реализовать
огромное многообразие требований различных предприятий.
ERP-системы удовлетворяют большинству запросов как средних, так и очень крупных предприятий. Они могут
работать на различных платформах (Windows NT, UNIX, Solaris, AIX и т.д.) и с различными мощными
профессиональными СУБД.
На мировом рынке представлено около трех десятков полноценных ERP-систем. В России систем подобного уровня
пока еще не создано. Затраты на создание ERP-системы оцениваются экспертами в несколько тысяч человеко-лет с
вытекающими отсюда финансовыми и организационными затратами. Кроме того, очень важным для столь сложных
информационных систем является процесс апробации на множестве предприятий. Только после нескольких десятков
успешных внедрений ERP-система может претендовать на рыночный успех, поскольку только тогда она аккумулирует в
себе достаточный опыт предметных специалистов и необходимые управленческие технологии.
Чтобы вернуть инвестиции и получить прибыль, компания-разработчик ERP-системы должна обеспечить ей
высокий уровень продаж. Но рынок России и стран СНГ, даже по самым оптимистическим оценкам, не способен пока
обеспечить спрос в миллиарды долларов за системы подобного класса. Это значит, что система должна хорошо
продаваться на западных рынках, прежде всего в США. Все без исключения лидеры рынка ERP-систем смогли занять
свои позиции только после успеха на самом богатом американском рынке. Так как у нас только начинается развитие
экономики предприятий на базе MRP/ERP – моделей, то пройдет немало времени, прежде чем в России появятся
специалисты, которые научатся не только разбираться в современных методах управления
предприятиями, но и
создавать программные продукты, реализующие эти методы. Однако ничто не препятствует уже сейчас использовать
мировой опыт применения информационных технологий для управления предприятиями, поскольку многие из ERPсистем представлены в России, переведены на русский язык и адаптированы к требованиям российского
законодательства.
Сейчас практически все современные западные производственные системы и основные системы управления
производством базируются на концепции ERP и отвечают её рекомендациям, которые вырабатываются американской
общественной
организацией
APICS,
объединяющей
производителей,
консультантов
в
области
управления
производством, разработчиков программного обеспечения. К сожалению, большинство из российских систем
управления производством не удовлетворяет пока даже требованиям MRP, не говоря уже обо всех остальных более
развитых концепциях.
Последний по времени стандарт CSRP (Customer Synchronized Resource Planning) охватывает кроме
управления непосредственно предприятием также и взаимодействие с клиентами: оформление технического
задания, наряд – заказа, поддержку заказчика на местах и пр. Таким образом, если MRP, MRP-II, ERP ориентировались
на внутреннюю организацию предприятия, то CSRP включил в себя полный цикл от проектирования будущего изделия,
с учетом требований заказчика, до гарантийного и сервисного обслуживания после продажи. Основная суть концепции
CSRP в том, чтобы интегрировать заказчика в систему управления предприятием. То есть не отдел сбыта, а сам
покупатель непосредственно размещает заказ на изготовление продукции - соответственно сам несет ответственность за
его правильность, сам может отслеживать сроки поставки, производства и пр. При этом предприятие может очень четко
отслеживать тенденции спроса и т.д.
На мировом рынке сейчас предлагается свыше 500 систем класса BMS (в том числе и системы класса MRP IIERP). Рынок бурно растет - на 35% - 40% каждый год. В настоящее время в России присутствуют около десятка
западных систем и три-четыре отечественные информационные системы, которые можно отнести к
корпоративным. Для того чтобы понять, кто есть кто на рынке информационных систем для предприятий
России, ниже предлагается классификация информационных систем (см. Таблицу 2).
В отечественной прессе в последнее время немало писали про якобы избыточную функциональность и дороговизну
системам стандарта ERP, апеллируя, как правило, к самым заметным представителям этого класса - продуктам SAP R/3,
Baan и Oracle Application. Действительно, помимо высоких цен, программные продукты этих корпораций сложны для
внедрения в российских условиях: во-первых, в России элементарно не хватает специалистов по внедрению достаточной
квалификации, а во- вторых, эти системы требуют от заказчика серьезной реорганизации управления.
Таблица 2. Тиражируемые интегрированные системы управления предприятием (ИСУП), представленные на
российском рынке
Крупные интегрированные ИСУП (ERP-системы) - универсальные
Название тиражируемой ИСУП
Класс
Поставщик на территории
России
R/3
ERP+
SAP СНГ
Вааn
ERP+
Альфа-Интегратор Баан Евразия
Oracle Applications (2*)
ERP II
Oracle CIS
OneWorld J.D. Edwards
ERP+
Robertson & Blums
MFG/PRO (разработчик QАD)
ERP+
Интерфейс – МФГ, BMS
Средние интегрированные ИСУП (ERP-системы) – специализированные
Название тиражируемой ИСУП
Класс
Поставщик на территории
России
iRenaissance. (разработчик Ross Systems) – для
процессного пр-ва
ERP
Интерфейс KC
CSRP
Socap
ERP
ICL-КПО ВС (Казань)
ERP
Форс
ERP
R-Style
ERPII
Columbus IT Partner, AND
(типа V)
SyteLine (разработчик Symix) (2*)
– для дискретного пр-ва (типа Т)
MAX (разработчик МАХ International) (2*)
- для дискретного пр-ва (типа Т)
IFS (Industrial & Financial Systems)
– для дискретного пр-ва (типа Т)
PRMS (разработчик Computer Associates) – для дискретного пр-ва
(типа Т)
Axapta (разработчик Damgaard, Дания)
– для дискретного пр-ва (типа А и Т)
Интегрированные ИСУП - для малых предприятий и средних предприятий (системы класса High End PC)
Название тиражируемой ИСУП
Класс
Поставщик
Concorde XAL
FTP+MRP
Columbus IT Partner
Exact
FTP+MRP
Exact Software
Platinum ERA2 (2*)
FTP+MRP
Platinum Software
Scala
FTP+MRP
Scala CIS
LS LIPro Systems (разработчик LIPro Systems, Германия)
FTP+MRP
ЛИПро Р
территории России
(разработчик Damgaard, Дания) (2*)
Protean (разработчик Wonderware)
NS-2000 (разработчик Никос-Софт) + Solagem Enterprise
PLC Systems
FTP+MRP
Никос-Софт
MRP
АйТи
(разработчик Solagem OY) (2*)
БОСС-Корпорация (с модулем "Производство") (2*)
Галактика (2*)
Галактика
Парус 8.x
MRP
Парус
БЭСТ-ПРО 3.02
MRP II
Интеллект-Сервис
SunSystems (фирмы Systems Union) +
MRP
Robertson & Blums
RB Manufacturing (разработчик
Robertson
&
Blums)
М-2
MRP
Клиент-серверные
на
технологии
АС+
MRP
Борлас
Флагман
MRP
Инфософт
Интегрированные ИСУП - для малых предприятий и средних предприятий без производства (системы класса
Middle End PC)
Название тиражируемой ИСУП
Поставщик на территории
России
Attain (разработчик Damgaard, Дания)
Columbus IT Partner
Монополия
Формоза-Софт
Эталон
Цефей
Альфа
Информконтакт
Аккорд
Атлант-Информ
1С: Предприятие 7.7 (с модулем "Производство")
1С
Локальные ИС - для малых предприятия (системы класса Low End PC )
Название тиражируемой ИСУП
Поставщик на территории России
1С:Бухгалтерия
1С
·БЭСТ,·Инотек,·ИНФИН,·Инфософт,·Супер-
Другие
Менеджер,·Турбо-Бухгалтер,·Инфо-Бухгалтер,·+более 100
систем
Приведенные в таблице системы отличаются от всех прочих присутствующих на российском рынке программных
продуктов для автоматизации финансово-хозяйственной деятельности (FTP), во-первых, наиболее развитой
функциональностью, а также тем, что в них или уже присутствует модуль планирования производства и оперативного
управления им (MRP), или разработчики системы обещают появление таких возможностей в ближайшие два года (т.е.
уже идет работа над реализацией этих задач). Достоинством и одновременно недостатком систем ERP уровня из первой
тройки (R/3, BAAN, Oracle Application) является их универсальность. Иными словами, у «гигантов» есть референтные
модели для любого типа производственного процесса, и количество автоматизированных рабочих мест определяется
исключительно финансовыми возможностями заказчика. Но и возможности эти должны быть серьезными. Проект с
использованием такой системы не может обойтись дешевле 500 тысяч долларов, а чаще всего стоит несколько
миллионов долларов. По сути, эти системы оптимальны для компаний, ведущих бизнес не менее масштабный, чем
бизнес самих разработчиков.
Для компаний среднего масштаба или имеющих не слишком диверсифицированный бизнес больше подходят другие
системы ERP. О них до недавнего времени потребители либо не слышали, либо не совсем понимали, на кого они
рассчитаны. Речь идет о западных продуктах для самого массового сегмента рынка - среднего и малого бизнеса, то есть
для компаний с годовым оборотом от 3 до 10 млн. долларов и количеством работающих от 100 до 1000 человек. Типовая
стоимость проекта по внедрению такой системы составляет от 50 до 250 тысяч долларов. Для сравнения: у российских
ИСУП этот показатель колеблется в пределах от 50 до 500 тысяч долларов для тиражно-заказных систем и до 10 тысяч для тиражируемых, или «коробочных».
Основное отличие систем ERP среднего уровня от программного обеспечения для крупных предприятий состоит в
ограниченности решаемых задач и относительной простоте технологий внедрения и применения. Иными словами, эти
системы поддерживают несколько определенных видов промышленной деятельности и имеют лимитированное
количество возможных пользователей.
В соответствии с мировой практикой, при необходимости более тонкого анализа нескольких систем одного или
близких классов, этапу выбора придается большое значение. Каждый проект в области автоматизации должен
рассматриваться предприятием как стратегическая инвестиция средств, которая должна окупиться за счет улучшения
управленческих процессов, повышения эффективности производства, сокращения издержек. В выборе правильного
решения должно быть, в первую очередь, заинтересовано руководство предприятия. Данный проект должен ставиться
на один уровень с приобретением, например, новой производственной линии или строительством цеха.
Прежде всего, предприятие должно определить, а что же собственно ожидается от новой системы: какие
функциональные области и какие типы производства она должна охватывать, какую техническую платформу
использовать, какие отчеты готовить?
Проведение такой работы заканчивается обычно составлением документа «Требования к компьютерной системе».
Он предназначен, прежде всего, для самого предприятия, так как в нем формализованы и расписаны в соответствии с
приоритетами все характеристики новой системы. Этот документ дает объективные критерии для сравнения систем по
заранее определенным параметрам. Любая из систем - лишь механизм для повышения эффективности управления,
принятия правильных стратегических и тактических решений на основе своевременной и достоверной информации.
Увеличение эффективности работы предприятия при внедрении ERP-системы могут быть достигнуты за счет:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
- уменьшение сроков закрытия учетного периода;
- повышения общей культуры управления, снижения бумажного документооборота, использования более
оптимальных схем построения бизнес – процессов;
- проведения поставок точно в срок;
- более эффективного использования средств предприятия за счет увеличения общей оборачиваемости как
всего капитала в целом, так и отдельных его частей;
- снижения транспортно-заготовительных расходов;
- улучшения послепродажного обслуживания;
- снижения задержек с отгрузкой готовой продукции;
- уменьшения страховых запасов (неснижаемых остатков на складах), внедрения прогрессивных методов их
планирования и контроля;
- снижения производственного брака;
- уменьшения затрат на административно-управленческий аппарат;
- более точного учета затрат;
- снижения потребности предприятия в оборотных средствах за счет повышения ритмичности работы;
- уменьшения складских площадей.
Как мы уже отмечали, в настоящее время не существует КИС российского происхождения, полностью отвечающих
требованиям модели ERP. Поэтому для рассмотрения возможных вариантов автоматизации предприятия были взяты
западные КИС, отвечающие требованиям ERP-модели и имеющие наилучшие позиции на российском и мировом
рынках ERP-систем (см. Таблицу 3).
Таблица 3. ERP - системы для предприятий
BAAN, BAAN IV
Для крупных предприятий
SAP, R/3
Oracle, Oracle Application
Для средних и крупных предприятий
QAD, MFG/PRO
BAAN, BAAN IV
Компания BAAN основана в 1978 г. в Нидерландах. В ней работает около 1000 человек. Система «BAAN» имеет
около 7000 внедрений за рубежом; 20 в России из них 2 проекта успешно завершены (Нижфарм – г. Н. Новгород, АО
«Элем» - г. Чебоксары). По оценкам внешних экспертов в России только на АО «Элем» удалось выйти на полное
использование стандартов MRPII.
В качестве СУБД используются: Oracle, Sybase, Informix.
Для разработки используются: Own 4GL – TRITON Tools
Архитектуры: Unix-сер., Win-кл.,Web-кл., RDA (двухуровневый клиент-сервер), AS (трехуровневый клиент-сервер).
Система ускоритель внедрения: Enterprise Modeler.
Система локализована в России в 1996 г.
В России систему представляет: BAAN-Евразия (Санкт-Петербург).
Финансовый модуль системы позволяет формировать отчетность Главной Книги в соответствии с российскими
стандартами.
Предназначена для крупных предприятий следующих отраслей:
BAAN IV имеет стандартную функциональность ERP-системы.
SAP, R/3
Компания основана в 1972 г. в Германии. В компании работает около 7000 человек.
Система имеет 13000 внедрений за рубежом, 15 в России.
В качестве СУБД используются: Oracle, Adabas, Informix.
Для разработки используются: ABAP/4GL.
Архитектуры: Unix-сер., Win-кл.,Web-кл., RDA (двухуровневый клиент-сервер), AS
(трехуровневый клиент-сервер).
Система ускоритель внедрения: Business Engineer.
Система локализована в России в 1996 г.
В России систему представляет: официальное представительство SAP в Москве.
Финансовый модуль системы позволяет формировать отчетность Главной Книги в соответствии с российскими
стандартами.
ERP-система R/3 компании SAP AG позиционируется как готовое решение информатизации для крупных
предприятий с конфигурациями для следующих направлений деятельности:
Oracle, Oracle Application
Компания основана в 1979 г. в США. В компании работает около 16500 человек из них 500 над ERP-системой.
Система имеет 8500 внедрений за рубежом, 10 в России.
В качестве СУБД используются: Oracle.
Для разработки используются: Oracle Designer.
Архитектуры: Unix-сер., Win-кл.,Web-кл., RDA (двухуровневый клиент-сервер), AS (трехуровневый клиент-сервер).
Система ускоритель внедрения: Application Implem Wizard.
Система локализована в России в 1998 г.
В России систему представляет: официальное представительство Oracle в Москве.
Финансовый модуль системы позволяет формировать отчетность Главной Книги в соответствии с российскими
стандартами.
ERP-система для крупных предприятий. Компанией разработаны решения для следующих отраслей:
QAD, MFG/PRO
Компания основана в 1979 г. в США. В компании работает около 1300 человек.
Система MFG/PRO имеет около 6000 внедрений за рубежом, 10 в России.
В качестве СУБД используются: Progress, Oracle.
Для разработки используются: Progress 4GL.
Архитектуры: Unix-сер., Win-кл.,Web-кл., RDA (двухуровневый клиент-сервер), AS
(трехуровневый клиент-сервер), хост -терминал.
Система ускоритель внедрения: Qwizard.
Система локализована в России в 1998 г.
В России систему представляют: российская компания Интерфейс - МФГ (Москва), американская компания BMS
(Нью-Джерси).
Финансовый модуль системы не позволяет формировать отчетность Главной Книги в соответствии с российскими
стандартами бухучета. Для формирования российской бухгалтерской отчетности разработана специальная программа,
связывающая MFG/PRO с российскими бухгалтерскими системами.
MFG/PRO - открытая система, работающая в архитектуре клиент-сервер с СУБД Progress или Oracle Data Server.
MFG/PRO
полностью
автоматизированную
русифицирована.
систему
управления
Система
MFG/PRO
представляет
производственно-хозяйственной
поддерживающую идеологию универсальных гибких цепочек процесса производства.
Предназначена для средних и крупных производственных предприятий.
Отрасли индустрии:
1.
2.
3.
4.
5.
- Машиностроение;
- Химическая и фармацевтическая;
- Пищевая;
- Производство товаров народного потребления;
- Производство электроники, электротехники, приборов;
собой
интегрированную,
деятельностью
предприятия,
6.
- Промышленное производство.
Функциональность:
1.
2.
3.
4.
5.
6.
7.
8.
9.
- Производство;
- Финансовые операции;
- Сбыт;
- Материально-техническое снабжение;
- Складское хозяйство;
- Транспорт;
- Управление проектом;
- Техническое;
- Сервисное обслуживание.
Объективные потребности российских предприятий диктуют использование наиболее современных технологий
корпоративного управления (на базе MRP/ERP стандартов). В настоящее время для отечественных предприятий
наиболее критичным являются ценовые характеристики ИСУП как по стоимости внедрения, так и по стоимости
лицензий.
Тема 8.
Информационные технологии и менеджмент качества
Связь между ERP-стандартами и стандартами качества серии
ИСО 9000
Существуют разные взгляды на организацию управления промышленным
предприятием. На многих отечественных предприятиях доминирующими являются
следующие мнения:
1) «наше предприятие уникально, и опыт других (особенно международный) для
нас мало приемлем»;
2) «если нам нужны изменения, то эти изменения должны быть радикальными и
принести быстрый результат» – идеология «Большого скачка».
Многие исследователи определяют данные умонастроения российского
менеджмента как препятствия на пути успешного развитии предприятий.
Можно с большой уверенностью утверждать, что:
во-первых - у предприятий существует специфики не более чем на 10 %, остальные 90 % деятельности стандартны. Для улучшения дел на таких предприятиях необходимо опираться на передовой опыт других и «не
изобретать велосипед». Квинтэссенцией такого опыта являются международные стандарты управления MRP-II, ERP,
CSRP, ISO 9000;
во-вторых – наши предприятия должны переломить существующее у них положение, когда сиюминутные
проблемы не дают реализоваться важным перспективным решениям. У предприятий должны появиться долгосрочные
цели. К этим целям они должны упорно двигаться, то есть изжить пустые иллюзии «большого скачка», заменив их на
идеологию постоянного совершенствования – Business Process Improvement (BPI).
Главным направлением развития экономики предприятий во всем мире (в том
числе и в России) является использование стандартизации методов управления.
Стандарты управления являются инструментами реализации концепции BPI (постоянного
совершенствования). Предприятия, внедряя передовые методики управления, получают
практические результаты в виде непрерывного улучшения, а также критерии оценки
достижения уровней совершенства (уровней BPI).
Сегодня многие отечественные предприятия не могут вырваться из кругооборота
вредных эффектов и проблем, таких как:
1) недостаточной гибкости взаимодействия с клиентом, что является
результатом слишком большого времени, необходимого на освоение новой
продукции или модификацию старой под требования заказчика;
2) низкий уровень удовлетворенности клиента из-за негибкости взаимодействия
с клиентом;
3) трудности прогнозирования сбыта, т.к. при низкой удовлетворенности
клиента нет уверенности, что клиент в следующий раз захочет закупить
продукцию;
4) ранние запуски продукции в производство, что является следствием
ухудшения точности прогнозов сбыта, а это приводит к хаотичным продажам,
которые невозможно предсказать, поэтому предприятие вынуждено работать не
на заказ, а на склад;
5) отсутствие возможности сокращения уровня запасов, из-за ранних запусков
в производство готовой продукции (ГП) по сравнению с реальными
потребностями реализации этой ГП;
6) повышение издержек на хранение СЗ в результате увеличения складских
запасов (СЗ) по материалам и ГП;
7) снижение оборачиваемости оборотных средств и увеличение накладных;
8) увеличение расходов на персонал (для поддержки детальных требований к
информации по планированию и управлению материальными ресурсами)
обуславливает замораживание капитала;
9) невозможность за необходимый период освоить новые продукты или
модифицировать старые под требования заказчика за счет существующих
ресурсов (возможности привлечения сторонних ресурсов, как правило,
отсутствуют), вследствие замораживания капиталов предприятия.
Таким образом, форма «узкого коммерческого мышления» приводит к созданию негибких производственных
систем. Решение любой из выше перечисленных проблем требует комплексного решения всех остальных проблем.
Ключевым фактором выхода из «замкнутого круга» является достижение баланса целей предприятия
(коммерческих, производственных и финансовых). Одинаково вредным для рентабельности является избыточное
давление либо производственных, либо финансовых, либо коммерческих целей предприятия.
Мировой опыт показывает, что успех достигли компании, которые:
1)
имеют системный взгляд на свою деятельность и рассматривают себя как единую производственносбытовую систему (ПСС), интегрируя такие сферы как маркетинг – создание новых изделий –
снабжение – производство – сбыт – доставку продукции потребителю – сервисное обслуживание;
2) используют для достижения технологической эффективности в качестве
главной бизнес-модели промышленные ERP-стандарты;
3) используют стандарты серии ИСО 9000 в качестве базы для повышения
качества готовой продукции.
Развитию стандартов ERP соответствует развитие принципов управления
качеством. Два этих направления («организация и управление производством» и
«управление качеством») неразрывно связаны между собой, и являются инструментами
повышения потенциала предприятия (под потенциалом понимается перспектива
получения предприятием прибыли в будущем).
Источником развития ERP-стандартов и стандартов качества является «Научная
организация труда» Ф. Тейлора. С развитием вычислительной техники (ВТ) произошло
разделение на систему управления производством, которая опиралась на
автоматизированную поддержку, и на систему управления качеством, которая больше
опиралась на бумажные процедуры и производственные философии. CALS-идеология,
появившаяся в середине 80 гг. прошлого века, протянула мостик между
«автоматизированными системами управления (АСУ) и проектирования (САПР)» и
«системой качества (СК)», вводя стандарты управления как структурированными
документами (характерными для АСУ), так и неструктурированными документами
(характерными для СК). С конца 80 гг. развитие АСУ было направлено в сторону
интегрированной информационной системы (ИИС), впитывающей в себя как CALSтехнологии, так и методологии системы качества.
Фундаментом такой интеграции стало:
1) унификация понятия «жизненного цикла продукции» как в ERP-стандартах,
так и в стандартах качества;
2) «Принцип непрерывного улучшения деятельности предприятия», что
заставило отказываться от жестких и застывших систем документирования
производственных процессов (СК) и перейти к динамичным моделям, что
невозможно без информационной поддержки таких моделей.
Таким образом, через пятьдесят лет раздельного развития, АСУ и СК в наше время
вновь соединяются во «Всеобщем менеджменте предприятия» (другое название - «Гибкая
система управления»). Прежний принцип специализации перестал работать. Чтобы
управлять всеми процессами (охватывать все функции на современном предприятии)
необходим целостный взгляд на объект управления, что невозможно без
компьютеризации процессов. Из-за усложнения процессов на предприятии разработка
уникальной интегрированной информационной системы, опирающейся только на опыт
данного предприятия стала не реальной. На помощь приходит «Компонентный подход» в
построении ИИС и промышленные стандарты (ERP-стандарты). Те, кто унифицируют
свою деятельность – выигрывают, а упорствующие в своей уникальности строят
«вавилонские башни» в области АСУ, которые обречены на то, чтобы рухнуть.
ERP-стандарты и стандарты качества как инструменты реализации принципа
«Непрерывного улучшения»
Уровни непрерывного улучшения бизнес-процессов (BPI)
Использование ERP-системы направлено на оптимизацию организации производства и управления предприятием,
то есть на улучшение бизнес-процессов предприятия BPI. Философия в BPI констатирует, что достичь совершенства
невозможно, но к нему нужно все время приближаться. BPI определяет уровни совершенства, или иначе уровни
непрерывного улучшения бизнес-процессов предприятия.
Декларируется пять уровней улучшения бизнес-процессов на предприятии:
1.
2.
3.
4.
5.
Динамик-Хаос - дисбаланс коммерческих, производственных и финансовых целей. Хаос характеризуется
отсутствием системного взгляда, предприятие рассматривается как совокупность отдельных элементов;
Контроль –Данный уровень подразумевает «налаженный» учет и контроль основных мероприятий на
предприятии;
Оптимизация – оптимизация (упрощение) основных бизнес-процессов на предприятии, что ведет к
снижению издержек;
Адаптация – адаптивность бизнес-процессов к условиям внешней среды;
Мировой класс – возможность предприятия формировать рынок.
Каждый BPI уровень можно охарактеризовать с точки зрения качества готовой
продукции и критериев управляемости процессов (то есть оценки бизнес – процессов на
полноту и точность).
Определяются следующие критерии управляемости процессов:
1. Процесс признан как таковой (соответствует уровню BPI «Динамик-Хаос»), характеризуется хаотичностью и
отсутствием стабильной внешней среды (ужас неопределенности); процессы на предприятии определены, но
представляются как «черный ящик», то есть при заданных входных данных непредсказуем результат, что ведет к
большим ошибкам в прогнозах и планировании (процессы на предприятии не имеют ни качественной, ни, тем более,
количественной оценки);
2.Процессы контролируемы (соответствует уровню BPI “Контроль»), характеризуется тем, что бизнес
приобретает более устойчивый характер, основные бизнес-процессы повторяемы и управляемы; становится возможной
успешная реализация задуманных проектов, но еще не достигается оптимизация, так как не точны нормативы
процессов; основные процессы имеют описание, делаются попытки их качественной оценки;
3.Процессы оптимизированы (соответствует уровням BPI «Контроль» и «Оптимизация»), характеризуется тем, что
полностью формализованы процессы как в управлении, так и в производстве; процессы документированы,
стандартизованы и объединены в единый информационный поток; существует возможность оперативного получения
информации о качестве использования ресурсов и проведения анализа по основным аспектам управленческой
деятельности, то есть проведено нормирование процессов, на основании которого достигается оптимизация
планирования; постановка долгосрочных целей базируется в основном на показателях предшествующего периода
(преобладает аналитический аспект); начинает развиваться управление корпоративными знаниями на базе
формирования системы метрик процессов;
4.Процессы адаптируемы (соответствует уровням BPI «Оптимизация» и «Адаптация»), характеризуется тем, что
приоритеты смещаются в сторону оценки качества процессов (ведущих к повышению качества продукции и услуг);
формируются внутрифирменные стандарты, цель которых количественное измерение качества всех процессов; планы
(стратегические и оперативные) получают количественную оценку; принятия плановых решений опирается на явные
знания, которыми обладает предприятие; стратегические и оперативные планы взаимоувязаны; обратная связь делает
возможным эффективное согласование между оперативным и стратегическим уровнем управления;
5.Процессы экономичны и гибки (соответствует уровням BPI «Адаптация» и «Мировой класс»), характеризуется
тем, что предприятие способно управлять качеством процессов по всей цепочке, включая поставки, производство, сбыт,
обслуживание; осуществляется оптимизация (то есть упрощение) бизнес-процессов; текущий контроль основан на
управлении изменениями; формализация процессов и рыночные перспективы позволяют просчитывать стратегические
планы и оптимизировать пути их достижения.
При определении уровней BPI декларируются следующие критерии оценки
«Качества готовой продукции»:
1. «Соответствие стандарту» подразумевает то качество продукции, которое
достижимо на существующем технологическом оборудовании предприятия и
соотносится с BPI-уровнями «Динамик-Хаос» и «Контроль». На предприятиях,
организация бизнес-процессов которых соответствует BPI уровню «Хаос»,
качество продукции является случайной величиной и напрямую зависит от
способностей отдельных сотрудников. Качество продукции для BPI уровня
«Контроль» уже является постоянной величиной за счет того, что предприятие
из «черного ящика» превращается в «прозрачную систему», где налажен четкий
производственный и управленческий учет и контроль.
2.
3.
4.
«Соответствие использованию» определяется не только соответствием стандарту предприятия, но и
удовлетворением эксплуатационных требований (потребностей потребителя). С этим уровнем качества
продукции соотносятся такие BPI уровни как «Контроль» и «Оптимизация».
«Соответствие фактическим требованиям рынка» подразумевает высокое качество продукции по
низкой цене. Продукция данного уровня качества может конкурировать с продукцией мировых
производителей. С данным уровнем соотносятся такие BPI уровни как «Оптимизация» и «Адаптация».
«Соответствие скрытым потребностям» качество продукции данного уровня направлено на
удовлетворение будущего спроса. Уровень «Соответствие скрытым потребностям» характерен для
предприятий BPI уровня «Мировой класс».
Цикл BPI перехода на следующий уровень
Переход с одного уровня BPI на вышестоящий предполагает использование:
1) набора взаимосвязанных процессов, которые при совместном выполнении
приводят к достижению набора целей, задаваемых для выхода на заданный
уровень BPI;
2) общих принципов процессов, определяющих каким должен стать процесс,
чтобы обеспечить достижение набора целей, задаваемых для выхода на
заданный уровень BPI (именуемых в дальнейшем практиками);
3) технологию реализации цикла BPI: использование определенного набора
методик входящих в ERP-стандарты и стандарты Системы менеджмента
качества; информационных технологий (ERP-система).
Переход предприятия с одного уровня BPI на вышестоящий (на базе ERP-системы)
подразумевает использование определенного набора ключевых практик - практик ERPстандарта, использование которых базируется на ERP-системе (интегрированной
информационной системе управления предприятием).
В основу перехода предприятия с одного уровня BPI на следующей положено
предварительное моделирование бизнес-процессов предприятия и внедрение новой
бизнес-модели в практику.
Для критерия оценки перехода на следующий уровень BPI выделяются только те
процессы, которые необходимы для данного перехода. Все оценки процессов нижних
уровней BPI присутствуют на более высших уровнях BPI, но с более детальными к ним
требованиями. Таким образом, переход с одного уровня BPI на вышестоящий
предполагает использование:
1) набора взаимосвязанных процессов, которые при совместном выполнении
приводят к достижению набора целей, задаваемых для выхода на заданный
уровень BPI (ключевых процессов - КП);
2) общих принципов процессов, определяющих каким должен стать процесс,
чтобы обеспечить достижение набора целей, задаваемых для выхода на
заданный уровень BPI (именуемых в дальнейшем ключевыми практиками
КПР);
3) технологию
реализации
цикла
BPI
(использование
приемов
и
информационных технологий).
Достижение всех целей в рамках КП для заданного уровня BPI определяет
соответствие организации данному уровню. Если хотя бы одна цель хотя бы одной КПР
для уровня BPI не достигнута, то организация не может соответствовать данному уровню
BPI.
КП можно разбить на три категории: управляющие, организационные и обеспечивающие.
Переход предприятия с одного уровня BPI на другой именуется циклом BPI. При
каждом цикле BPI используются определенный набор методик, входящих в ERPстандарты и стандарты Системы Качества.
Цикл BPI - балансировка и внутренняя рационализация (переход
с I уровня на II)
На данном цикле ставится задача внедрения в реальное пользование методики
MRP-II и производственного учета. В рамках ERP-системы должны быть определены и
отлажены:
1) система учета затрат;
2) система многоуровневого планирования (MRP-II);
3) система контроля и диспетчирования.
Использование MRP-II на данном цикле BPI позволяет предприятию продвинуться от "Динамик-Хаос" к "Контролю"
и осуществить балансировку производственных, коммерческих и финансовых целей предприятия за счет
многоуровневого планирования.
Совместно с внедрение MRP-II подразумевается и внедрение ERP-системы, где
ERP является развитием MRPII с точки зрения охвата операционного менеджмента и
финансовых потоков.
Цикл BPI - объединение с поставщиками (переход с II уровня на
III)
Только после выхода предприятия на II-й уровень BPI могут быть по-настоящему
эффективны поставки «точно в срок» (JIT), без избыточных хранилищ и обработки
материалов.
Данный цикл развивает связи с поставщиками и подразумевает решение таких
задач как:
задачи анализа данных о затратах и результатах хозяйственной деятельности в разрезе необходимых для
управления объектов;
2) задачи оперативного принятия управленческих решений для расшивки узких мест и оптимизации
финансовых результатов;
3) задачи взаимодействия с поставщиками для понимания и поддерживания общих требований к
деятельности предприятия.
Философия JIT помогает предприятию оптимизировать достижение сбалансированных целей, вводя критерии
1)
оценки эффективности плана. Философия JIT гласит, что - убыточно все, что увеличивает издержки, но не
увеличивает ценность продукции. Основные принципы JIT ориентированы на:
1) повышение эффективности производства (снижение длительности цикла), повышение качества (принцип «ноль дефектов»),
2) активизацию человеческого фактора.
JIT призвана обеспечить производство качественной продукции по более низкой
цене за более короткое время. Реализация философии JIT для средних и крупных
предприятий базируется на использовании ERP-системы.
Цикл BPI - рационализация и развитие клиентов (переход с III
уровня на IV)
Этот цикл начинается только после того, как процессы I –го и II-го уровней BPI
работают, и на предприятии реализуется идеология JIT «точно в срок».
На данном цикле налаживается взаимодействие с клиентами с целью
совершенствования продукции и перспективного планирования рыночных тенденций,
наряду с философией JIT начинает использоваться методология CSRP.
CSRP делает возможным планирование ресурсов предприятия в зависимости от потребностей клиента, осуществляя
адаптацию бизнес-процессов к внешней среде за счет интеграции предприятия с внешними агентами.
MRP и ERP методологии охватывают производственный и логистический циклы
изделия. Методика CSRP охватывает весь жизненный цикл товара.
Методология CSRP позволяет при планировании и управлении предприятием
учитывать не только основные производственные и материальные ресурсы предприятия,
но и все те ресурсы, которые обычно рассматриваются как «вспомогательные» или
«накладные».
CSRP перемещает фокус внимания с планирования производства к планированию
заказов покупателей. Производственное планирование не просто расширяется, а
замещается требованиями клиентов, поступающими из подразделений, ориентированных
на работу с покупателями.
CSRP заставляет пересмотреть бизнес-логику, фокусируя её на рыночной
активности, а не на производственной деятельности. Бизнес-процессы синхронизируются
с деятельностью покупателей. Результаты успешного применения CSRP - это повышение
качества товаров, снижение времени поставки, повышение потребительской ценности
продукции, и т.д., а в результате этого:
1) снижение производственных издержек,
2) развитие инфраструктуры для создания индивидуализируемых,
конфигурируемых решений;
3) улучшение обратной связи с покупателями;
4) обеспечение лучшего сервиса для покупателя.
Это не технологическая эффективность, которая обеспечивает лишь временное
конкурентное преимущество, это - способность создавать продукты, удовлетворяющие
разнообразным потребностям покупателя и лучший сервис, то есть – получение
устойчивого конкурентного преимущества.
Цикл BPI - одержимость качеством (переход с IV уровня
на V)
Управление качеством рассматривается как составная часть общей системы
управления предприятием. Система Качества присутствует во всех элементах
управления бизнесом как критерий достижения постоянного роста потенциала
предприятия и на всех уровнях BPI.
Стандарт системы качества ИСО 9000:2000 базируется на философии «тотального
управления качеством» (TQM), которая может быть определена как оптимизация
деятельности всех частей и функций организации.
Цель данного цикла BPI – внедрение на предприятии культуры качества, где
каждый стремится к непрерывному усовершенствованию во всем, что делается в
каждодневной работе. TQM включает базовые элементы, которые существенно
расширяют понятие системы качества и могут быть реализованы с помощью ERPсистемы.
Результаты, необходимые для выхода на следующий уровень BPI
Ключевые процессы
на II-й уровень BPI
и
экономический
эффект
перехода
Переход с I–го на II-й уровень BPI предполагает использование ключевых
процессов, которые при совместном выполнении приводят к достижению целей
внедрения новой бизнес - модели предприятия на базе методики MRP-II и технологий
ERP-системы.
Ключевыми процессами при достижения II уровня BPI являются:
1) управление требованиями клиентов;
2) планирование;
3) диспетчирование производства;
4) управление снабжением;
5) обеспечение качества;
6) управление складскими запасами.
Практическое использование MRP-II при реализации новой бизнес-модели
приводит к сокращению:
1)
2)
логистического цикла, то есть времени перемещения материальных потоков от поставщика к
потребителю продукции;
производственного цикла, то есть длительности изготовления продукции;
Сокращение логистического цикла происходит:
1. За счет сокращения страховых запасов материалов. Страховые запасы
формируются из-за того, что никто на предприятии не знает времени
доставки материалов поставщиками, нормирование данного времени по
элементам номенклатуры и по поставщикам, накопление статистик и выбор
поставщика с учетом «надежности поставок», ведет к предсказуемости
длительности срока поставок и к сокращению страховых запасов
материалов.
2. За счет сокращения запасов готовой продукции. Введение в практику
прогнозов отгрузки ГП, накопление статистики по потребности ГП
потребителями (то есть точного прогнозирования), и точного запуска в
производство выпуска ГП (то есть работать под заказ, а не на склад).
Сокращение производственного цикла происходит:
1) за счет сокращения времени настройки оборудования и времени перемещения;
2) за счет оптимального расчета партий запуска деталей;
3) за счет сокращению времени выпуска изделий, исключив возвраты по
технологическим операциям и переделу брака.
Это достигается с помощью набора статистики дефектов по рабочим центрам,
работникам, деталям, техкартам, и с помощью строгой технологической дисциплины,
когда наряд - задание не запускается в производство, если нет спецификации и техкарты
изготовления.
Сокращение данных циклов ведет к сокращению складских запасов (по данным
западных исследователей от 15 до 50 %) и уровня незавершенного производства (НЗП).
Внедрение MRP-II на базе ERP-системы имеет также и косвенные выгоды, такие
как:
1) снижение доли непроизводительного труда за счет сокращения процессов, не
приносящих добавочную стоимость;
2) сокращение коммерческого цикла за счет более четкой организации
оформления и заключения заказов на продажу и закупку;
3) сокращение цикла оборачиваемости оборотных средств за счет более четкой
организации управления счетами дебиторов и кредиторов;
4) повышение гибкости реагирования на требования потребителей.
Фиксация фазы внедрения новой бизнес-модели осуществляется только после того,
как предприятие начинает получать реальную экономическую выгоду от использования
MRP-II.
Оценка достижения II-го уровня BPI по ключевым процессам
Ниже приводятся цели КП и количественные показатели их достижениях для
уровня BPI «Контроль», где делается акцент на поэтапное достижение целей КП за счет
пошагового внедрения практик КП, которое позволит предприятию достичь уровень BPI
«Контроль»:
1) 0% - практики КП не внедрены. Описание в бизнес-модели желаемых способов
выполнения КП (1 этап). Данный этап позволяет проиграть разные сценарии
улучшения, то есть разные комбинации желаемых способов выполнения
процессов предприятия;
2) 20% - внедрено 20% от объема всех практик КП(2 этап);
3) 60% - внедрено 60% от объема всех практик КП (3 этап);
4) 100 - внедрено 100% от объема всех практик КП (4 этап);
Далее будут рассмотрены цели в Ключевых Процессах. Ключевые Процессы
соотносятся с элементами стандарта ИСО 9001:2000. Качественная и количественная
оценка Ключевых Процессов соответствует следующим уровням BPI:
1) 20 % - 1-й уровень BPI;
2) 40 % - 2-й уровень BPI;
3) 60 % - 3-й уровень BPI;
4) 80 % - 4-й уровень BPI;
5) 100 % - 5-й уровень BPI.
Таким образом, достижение 40% по всем шести Ключевым процессам будет
означать, что предприятие вышло на II-й уровень BPI. Если хотя бы у одного ключевого
процесса не достигнута оценка 40 %, то считается, что предприятие находится на первом
уровне BPI.
Планирование
КП «Планирование» в общем контексте внутрифирменного планирования является
одним из уровней многоуровневого планирования, включающего:
1) «Стратегическое и годовое тактическое планирование», определяющее задачи
финансовые результаты, которые организация хочет достичь в заданный
плановый период;
2) «Объемно-календарное планирование», определяющее понедельный график
выпуска готовой продукции.
3) «Наряд-Задание на выполнение работ», подразумевающее детализацию
выполнения работ до индивидуальных заданий исполнителям с определением
технологической карты и маршрута изготовления ДСЕ, комплектации
материалов, нормативной себестоимости работ, критериев качества.
Первый уровень планирования реализуется с помощью финансового планирования
с детализацией данного плана по отдельным бюджетам предприятия.
Второй уровень планирования не является жестким требованием, а, скорее,
прогнозом производства и реализации продукции.
Требования к исполнению точно в срок планового задания связано не со II-м, а с
III-м уровнем планирования – «Задание на выполнение работ».
КП «Планирование» ставит следующие цели:
1) базовые данные, используемые для планирования (нормативы на
организационный и элементные аспекты), должны подлежать формализации,
учету в ИС и непрерывному уточнению;
2) реализация планов должна отслеживаться;
3) действия и обязательства по осуществлению планирования должны стать
повседневной практикой. Задействованные группы и личности должны
выполнять обязанности, связанные с планом.
Ключевыми приемами (для данного КП) являются следующие методики:
1. Для I-го уровня планирования: Управление планированием продуктовой линии
ТНГ; Управление укрупненным планированием ресурсов (RCP);
2. Для II-го уровня планирования: Управление планирования Главного
Календарного Графика/ MPS; Управление планированием Возможности
Использования Ресурсов (RCCP);
3. Для III-го уровня планирования: Управление планированием потребности
материалов (MRP); Управление планированием потребности мощностей (CRP);
4. Управление планированием возможностей распределения (DRP).
Управление требованиями потребителя
В КП «Управление требованиями» описывается порядок действий,
обеспечивающий появление понятных всем сторонам (и заказчику и исполнителю)
требований к конечному продукту, то есть - «Заказ на продажу» с параметрами,
удовлетворяющими, как потребителя, так и поставщика. Таким образом, целью КП
является, чтобы требования:
1) были согласованны с потребителем ГП и условиями поставки ГП;
2) должны быть исполнимыми, выгодными для предприятия, контролируемыми и
являться основой для планирования и диспетчирования производства.
Ключевыми приемами (для данного КП) являются следующие методики:
управление ценообразованием;
управление «Заказами на продажу»;
управление «Долгосрочными контрактами с потребителями»;
управление отправками потребителям;
управление сервисными услугами потребителю;
управление конфигурированием изделий под заказ;
управление счетами дебиторов;
управление анализом продаж.
1)
2)
3)
4)
5)
6)
7)
8)
Управление снабжением
КП «Управление снабжением» определяет процессы, связанные с оценкой,
выбором и организацией работ с поставщиками. Данный КП определяет следующие цели:
1) предприятие должно выбирать только качественных поставщиков (не более
трех на каждый вид материала или покупные) и строить отношения на
долгосрочной основе, поддерживать постоянную связь;
2) предприятие и поставщик должны согласовать друг с другом свои
обязательства, заключив долгосрочные контракты на поставку;
3) предприятие должно постоянно отслеживать реальные результаты деятельности
поставщика в сравнении с его обязательствами. Результаты анализа должны
быть формализованы и учтены в ИС посредством отслеживания нормативов по
времени доставки материалов и точке заказа.
Ключевыми приемами (для данного КП) являются следующие методики:
1)
2)
3)
4)
5)
6)
7)
8)
управление «Заявками на Закупку»;
управление «Заказами на Закупку»;
управление «Долгосрочными контрактами с поставщиками»;
управление получением/возвратом материалов;
управление входным контролем качества материалов и прослеживаемостью полученной партии
материалов;
управление прайс-листами поставщиков и нормативами по доставке продукции;
управление счетами кредиторов;
управление анализом деятельности поставщиков.
Диспетчирование производства
КП «Диспетчирование» подразумевает учет процесса выполнения работ по
закрытию Наряд Заданий. В рамках данной КП производится детальное диспетчирование
по видам работ в разрезе каждого конкретного исполнителя и Рабочего Центра, тем самым
накапливаются статистические данные для формирования метрик (количественных
характеристик действующих процессов предприятия). Процесс диспетчирования
подразумевает автоматическое накопление данных для их дальнейшего анализа и
преобразования в нормативы.
При наличии третьего уровня планирования контроль за ходом проекта
необходимо производить в рамках спланированных заданий, обеспечивая реальное
диспетчирование работ и исполнения плановых заданий, контроль за возникновением
узких мест в реальном режиме времени.
Данный КП ставит следующие цели:
1. Базовые данные, используемые при диспетчировании (нормативы на
организационный и элементные аспекты), должны подлежать формализации,
учету в ИС и непрерывному уточнению;
2. Результаты и характеристики выполняемых работ должны постоянно
сравниваться с нормативами. Корректирующие действия должны выполняться
тогда, когда действительные результаты значительно отклонились от плановых.
Ключевыми приемами (для данного КП) являются следующие методики:
1)
2)
3)
4)
5)
6)
7)
8)
управление спецификациями изделия (формулами изготовления);
управление техкартами (процессами);
управление Рабочими Центрами;
управление нормативной и текущей себестоимостью изделия;
управление производственными рабочими;
управление Наряд-Заданиями;
управление производственным контролем;
управление поточным производством.
Обеспечение качества Готовой Продукции
Данный КП определяет следующие цели:
1) деятельность по контролю качества продукции должна планироваться:
нормативы по качеству, последовательность действий в рамках управления
качеством;
2) должен обеспечиваться объективный контроль за строгим соответствием
продукции и процессов принятым стандартам, процедурам и требованиям;
3) задействованные группы и конкретные работники должны информироваться о
действиях по обеспечению качества и об их результатах;
4) вопросы несоответствия требованиям, которые невозможно разрешить в
оперативном режиме, должны решаться на высшем уровне организации.
Ключевыми приемами (для данного КП) являются следующие методики:
управление нормативами по качеству продукции (тесты);
управления Заказами Качества;
управление операциями контроля качества в рамках Наряд-Заданий;
управление учетом брака, исправления брака, простоям по Наряд-Заданиям в
разрезе операций, работников и рабочих центров;
5) управление статистикой по итогам контроля качества;
6) управление дефектами оборудования и др. производственных элементах.
1)
2)
3)
4)
Управление складскими запасами
Данный КП ставит следующие цели:
1) складские Запасы должны быть пронормированы (по требованию к складским
помещениям, по точке заказа, по стоимости, по фрахту, по срокам хранения);
2)
используемые для производства материалы и ДСЕ должны быть идентифицируемы, управляемы и
прослеживаемые.
Ключевыми приемами (для данного КП) являются следующие методики:
1) управление складской инфраструктурой;
2) управление элементами запасов и складскими нормативами по позициям;
3) управление контролем Складских Запасов;
4) управление инвентаризацией;
5) управлением АBC-анализом Складских Запасов.
Заключение
Внедрить новые технологии можно за 1 год.
Внедрить новые методики управления можно за 2 года.
Внедрение новой производственной философии осуществляется минимум 4 года.
Переход предприятия с одного уровня BPI на следующий есть в большей степени
изменение производственной философии на предприятии, а методики и технологии
являются инструментами данного культурологического преобразования предприятия.
Внедрение ERP-системы можно рассматривать как начало процесса значительного
улучшения организации и управления предприятием, начало перехода предприятия на
новые производственные философии. Для успешного внедрения ERP-системы
необходимо учитывать, что именно ЛЮДИ, работающие на предприятии, могут
использовать или не использовать методик MRP-II, JIT, CSRP, заложенные в основу
данной Информационной Системы. Для того, чтобы ЛЮДИ прониклись новыми
методиками, необходима программа обучения. Закрепление программы обучения и
обеспечение регулярного использования методик в рамках ERP-системы осуществляется
методами Системы Качества (методы обеспечения качества, методы стимулирования
качества, методы контроля результатов по качеству) и базируется на принципах
«Лидерства» и «Вовлечение персонала».
Таким образом, успешное использование принципа «Непрерывного улучшения»
(BPI) основывается на пересечении трех областей знаний:
 Область А - развитие Информационных Технологий;
 Область В - развитие бизнес-платформ;

Область С определяет “психологию труда”.
Область А - развитие Информационных Технологий:
1) использование профессиональных операционных систем (для серверов Баз
Данных) и персональных компьютеров;
2) использование профессиональных Систем Управления Базами Данных (СУБД);
3)
использование ERP-систем как ядра Интегрированной Информационной Системы предприятия;
4) использование кооперативных технологий, обеспечивающих компьютерную
поддержку параллельной согласованной работы группы («команды»)
сотрудников над одним проектом, документом и т. п.;
5) использование телекоммуникации, позволяющую исключить передачу
бумажных документов и личных встреч, свести к минимуму необходимость
переездов для проведения совещаний;
6) использование Систем Управления Знаниями для организации хранилища и
поиска неструктурированных документов.
Область В - развитие бизнес-платформ, включающей:
1) методики Управления Качеством (то есть целостная идеология управления
предприятием) на базе стандартов ИСО серии 9000 в редакции 2000 г.;
2) методики Организации операционного менеджмента (ERP-стандарты);
3) методики Управления требованиями и конструкторскими разработками (CALSстандарты);
4) методики моделирования бизнес-процессов (SADT, IDEF0, DFD, UML).
Область С определяет “психологию труда” и направлена на решение следующих
задач:
1) внедрение принципа «Лидер Область С определяет “психологию труда” ства»
(устранение недостатков производственной системы, а не отдельных
работников);
2) внедрения принципа «Вовлечения работников» (повышение значимости и
инициативности каждого работника);
3) снятие барьеров между производственными подразделениями, организация
групповой «артериальной работы»; образование так называемых «плоских»
рабочих групп, использующих эдхократические (эдхократия – компетентная
бюрократия) способы управления, опирающиеся на Информационные
Технологии и организующие динамическое и неформальное распределение
прав и обязанностей сотрудников группы (такие группы реактивны, никому не
дают монополию на истину, требуют проработку альтернативных решений);
4) формирование корпоративной культуры и повышения эдхократии в
организации;
5) внедрения философии Тотального Управления Качеством на всех рабочих
местах (TQM);
6) внедрение философии организации производственных процессов «Точно во
время» на всех рабочих местах (JIT).
В недавнем прошлом руководители отечественных предприятий, осознавая
значительные культурные различия между нами и Западом, предполагали, что западные
методики не будут работать в России. Однако когда ряд западных фирм открыли свои
производства в России и добились успеха на нашем рынке, всем стало ясно, что
рассмотренные выше методики могут успешно работать и на отечественных
предприятиях.
Лекция
Рынок информационных продуктов и услуг
Характерной чертой современного общества является производство услуг и
информации, значительно превышающее производство товаров. Активное движение России
по пути рыночных реформ, интеграция в мировое торговое сообщество делают необходимым
быстрое освоение новых методов хозяйствования, внедрения интенсивных
энергосберегающих технологий производства, освоения новых рынков сбыта. В связи с
этим актуальным для России становится развитие рынка профессиональных
консультационных и информационных услуг.
Консультационный бизнес в России, как и во всем мире, является одним из наиболее
динамично развивающихся секторов экономики. По темпу роста он уступает только рынку
информационных технологий. Эта динамика обусловлена тем, что согласно теории смены
технологических укладов в экономике, современное общество находится в фазе активного
формирования пятого технологического уклада, который характеризуется развитием сектора
услуг, геоинформационных технологий, телекоммуникаций, биотехнологий и т.д.
Характеристика рынка информационных продуктов и услуг
Прежде, чем приступить к характеристике рынка информационных продуктов и услуг,
нужно пояснить, что такое информационный продукт и информационная услуга. Базой для
создания информационных продуктов являются информационные ресурсы.
Ресурс - запасы, источники чего-либо. В информационном обществе акцент внимания
и значимости смещается с традиционных видов ресурсов на информационный ресурс,
который, хотя всегда существовал, не рассматривался ни как экономическая, ни как иная
категория; никто специально о нем не говорил и тем более не вводил никаких определений.
Одним из ключевых понятий при информатизации общества стало понятие
«информационные ресурсы». Этому вопросу посвящено довольно много публикаций, в
которых отразились и разные мнения и определения, и разные научные школы,
рассматривающие эти понятия. С принятием Федерального закона «Об информации,
информатизации и защите информации» большая часть неопределенности была снята.
Руководствуясь не научной стороной этого вопроса, а скорее прагматической позицией
потребителя информации, целесообразно воспользоваться тем определением, которое
приведено в этом законе. Тем более нельзя не учитывать тот факт, что юридическое
толкование во всех случаях является для пользователя информации опорой при защите
его прав.
Информационные ресурсы - отдельные документы и отдельные массивы документов,
документы и массивы документов в информационных системах (библиотеках, архивах,
фондах, банках данных, других информационных системах).
Документы и массивы информации, о которых говорится в законе, не существуют
сами по себе. В них в разных формах представлены знания, которыми обладали люди,
создававшие их. Таким образом, информационные ресурсы - это знания, подготовленные
людьми для социального использования в обществе и зафиксированные на материальном
носителе.
Любой информационный продукт отражает информационную модель его
производителя и воплощает его собственное представление о конкретной предметной
области, для которой он создан. Информационный продукт, являясь результатом
интеллектуальной деятельности человека, должен быть зафиксирован на материальном
носителе любого физического свойства в виде документов, статей, обзоров, программ, книг и
т.д.
Информационный продукт - совокупность данных, сформированная производителем
для распространения в вещественной или невещественной форме.
Информационный продукт может распространяться такими же способами, как и любой
другой материальный продукт, с помощью услуг.
Услуга результат непроизводственной деятельности предприятия или лица,
направленный на удовлетворение потребности человека или организации в использовании
различных продуктов.
Информационная услуга - получение и предоставление в распоряжение пользователя
информационных продуктов.
В узком смысле информационная услуга часто воспринимается как услуга,
получаемая с помощью компьютеров, хотя на самом деле это понятие намного шире.
При предоставлении услуги заключается соглашение (договор) между двумя сторонами
предоставляющей и использующей услугу. В договоре указываются срок ее использования и
соответствующее этому вознаграждение. Перечень услуг определяется объемом, качеством,
предметной ориентацией по сфере использования информационных ресурсов и создаваемых
на их основе информационных продуктов. Например, библиотека является местом
сосредоточения значительной части информационных ресурсов страны.
Информационные услуги возникают только при наличии баз данных в
компьютерном или некомпьютерном варианте.
База данных - совокупность связанных данных, правила, организации которых
основаны на общих принципах описания, хранения и манипулирования данными.
Базы данных являются источником и своего рода полуфабрикатом при подготовке
информационных услуг соответствующими службами. Классификация баз данных помогает
систематизировать информационные услуги и продукты. Базы данных принято разделять на
библиографические и небиблиографические.
Библиографические базы данных содержат вторичную информацию о документах,
включая рефераты и аннотации. Небиблиографические базы данных имеют множество
видов: справочные, числовые, текстово-числовые, юридические, финансовые.
Опираясь на вышеизложенное, можно классифицировать информационные услуги в
соответствии со схемой рисунка 9.1:
Рисунок 9.1 - Основные виды информационных услуг
Понятие рынка информационных продуктов и услуг
Как и при использовании традиционных видов ресурсов и продуктов, люди
должны знать: где находятся информационные ресурсы, сколько они стоят, кто ими
владеет, кто в них нуждается, насколько они доступны.
Ответы на эти вопросы можно получить, если существует рынок информационных
продуктов и услуг.
Рынок информационных продуктов и услуг, (информационные рынок) - система
экономических, правовых и организационных отношений по торговле продуктами
интеллектуального труда на коммерческой основе.
Информационный рынок характеризуется определенной номенклатурой продуктов
и услуг, условиями и механизмами их предоставления, ценами. В отличие от торговли
обычными товарами, имеющими материально-вещественную форму, здесь в качестве
предмета продажи или обмена выступают:
аа) информационные системы;
бб)
информационные технологии;
вв)
лицензии;
гг) патенты;
дд)
товарные знаки;
ее) ноу-хау;
жж)
инженерно-технические услуги;
зз) различного рода информация;
ии)
прочие виды информационных ресурсов..
Основным источником информации для информационного обслуживания в
современном обществе являются базы данных. Они интегрируют в себе поставщиков и
потребителей информационных услуг, связи и отношения между ними, порядок и условия
продажи и покупки информационных услуг.
Поставщиками информационных продуктов и услуг могут быть:
кк)
центры, где создаются и хранятся базы данных, а также
производится постоянное накопление и редактирование в них
информации;
лл)
центры, распределяющие информацию на основе разных
баз данных;
мм)
службы телекоммуникации и передачи данных;
нн)
специальные службы, куда стекается информация по
конкретной сфере деятельности для ее анализа, обобщения,
прогнозирования, например консалтинговые фирмы, банки,
биржи;
оо)
коммерческие фирмы;
пп)
информационные брокеры.
Потребителями информационных продуктов и услуг могут быть различные
юридические и физические лица, решающие задачи.
Структура рынка информационных продуктов и услуг
Совокупность средств, методов и условий, позволяющих использовать
информационные ресурсы, составляет информационный потенциал общества. Это не только
весь индустриально-технологический комплекс производства современных средств и
методов обработки и передачи информации, но также сеть научно-исследовательских,
учебных, административных, коммерческих и других организаций, обеспечивающих
информационное обслуживание на базе современной информационной технологии.
Важнейшими компонентами рынка информационных продуктов и услуг являются:
1. Техническая и технологическая составляющая. Это современное
информационное
компьютерная
оборудование,
сеть
и
мощные
соответствующие
компьютеры,
им
развитая
технологии переработки
информации. В настоящее время в России получили распространение такие
современные мировые технические достижения, как возможность работы в
глобальной
компьютерной
сети
что
Internet,
позволяет
вывести
информационные ресурсы России на мировой рынок, Web-технология
ведения гипертекстовой среды, электронная почта в компьютерной сети
РЕЛКОМ.
2. Нормативно-правовая составляющая. Это юридические документы: законы,
указы, постановления, которые обеспечивают цивилизованные отношения
на информационном рынке (закон «Об информации, информатизации и защите
информации», закон "Об авторском праве и смежных правах", закон "О
правовой охране программ для ЭВМ и баз данных", закон " О правовой
охране топологий интегральных схем").
3. Информационная составляющая. Это справочно-навигационные средства и
структуры,
помогающие
«Российская
обобщены
энциклопедия
сведения
об
находить
нужную
информации
информационной
и
информацию.
Например
телекоммуникаций»,
структуре
рынка,
где
включая
производителей и распространителей.
4. Организационная
регулирования
составляющая.
взаимодействия
Это
элементы
производителей
и
государственного
распространителей
информационных продуктов и услуг.
В нашей стране, претерпевающей серьезные экономические изменения,
организационный фактор государственной политики становится особенно актуальным.
Следовательно, формирование информационного рынка и решение всех сопутствующих
этому процессу проблем наше государство во многом должно взять на себя.
Лицензионная политика. Виды лицензий.
Известно, что программное обеспечение защищено законом об авторских правах.
Только автор может производить копии программных продуктов и предоставлять
лицензионное право на использование программного обеспечения. Предоставление такого
права осуществляется через специальное соглашение, называемое «Лицензионным
соглашением конечного пользователя» или «END-USER LICENSE AGREEMENT (EULA)».
Лицензионное соглашение конечного пользователя определяет, как и на каких условиях
получатель лицензии может использовать программный продукт.
В настоящее время у крупных предприятий, следящих за лицензионной чистотой
используемых внутри предприятия программ, возникает много трудностей с управлением
и учетом используемого программного обеспечения. Проблемы возникают также во время
дополнительных закупок ПО при расширении организации, при обновлениях версий ПО.
Кроме того, сама периодическая организация таких закупок для предприятия отнимает
достаточно много времени, требует тщательной ценовой оптимизации и наличия
высококвалифицированных специалистов по лицензированию ПО. Для организаций с
разветвленной структурой подобные работы могут требовать немалое количество
трудовых ресурсов.
Во всем мире - и наша страна не исключение - практикуется продажа
программного обеспечения (ПО) по так называемым «программам лицензирования»:
1. Коммерческие лицензии. Цена единичной лицензии зависит от количества
покупаемых программных продуктов.
2. Академические (образовательные) лицензии - лицензии, распространяемые
только среди учебных заведений. У компаний они имеют фиксированную,
минимально возможную цену. При покупке ПО образовательными
организациями
необходимо предоставить документы, подтверждающие
статус учреждения как образовательный.
3. Государственные лицензии - лицензии, распространяемые исключительно
среди
государственных
организаций
(министерств,
государственных
органов).
Коммерческая лицензия – это лицензионное соглашение (Full License) между
пользователем и компанией, подтверждающее факт того, что владелец данного документа
имеет право на коммерческое использование данного продукта на определенном количестве
компьютеров (рабочих мест). Соглашение состоит из двух частей: электронной (pdf-файла)
и бумажной, которая предоставляется покупателю. Покупая лицензии, пользователь сам
определяет необходимое количество комплектов.
Основными видами лицензионных соглашений являются:
рр)
лицензия на рабочее место;
сс)
лицензия для конечного пользователя;
тт)корпоративная лицензия;
уу)
лицензия на использование ПО;
фф)
OEM-лицензия;
хх)
«коробочная» лицензия;
цц)
«оберточная» лицензия;
чч)
Click wrap-лицензия.
Лицензия на рабочее место ограничивает применение программных продуктов
одним рабочим местом с заранее определенным количеством пользователей.
Разновидностью на лицензию рабочего места являются: сетевая и site-лицензию. Сетевая
лицензия предполагает возможность развертывания программных средств в локальной
сети корпорации, а в site-лицензии дополнительно включается условие на использование
программы в определенном здании.
Лицензия для конечного пользователя (END-USER LICENSE AGREEMENT - EULA)
представляют право применять ПО на любой рабочей станции только конкретному
физическому лицу. В зависимости от вида программного продукта пользователям
представляется различный объем прав на его использование: при приобретении
прикладной программы пользователь имеет право установить ее только на одном
компьютере, а вторую копию подготовить для личного использования на портативном
компьютере; в лицензионных соглашениях на процессор необходима отдельная лицензия
на каждый процессор или сервер. Допускается обращение к этому серверу произвольного
количества клиентских рабочих станций.
Корпоративная лицензия приобретается для использования программного
обеспечения в рамках всей компании. При наличии у организации такой лицензии любому
сотруднику предоставляется право работы с программным обеспечением. Лицензии
такого вида являются наиболее дорогостоящими и приобретаются крупными компаниями,
в которых с одинаковыми программными продуктами работают большое количество
сотрудников.
Лицензия разработчика (development license) дает право применения ПО для
разработки и/или тестирования приложений, а также для их установки, развертывания,
запуска и последующей поддержки приложений. Основными типами таких соглашений
являются следующие: лицензия для рабочей группы, представляющая право на разработку
и тестирование приложения группе программистов; лицензия на конкретный проект,
содержащая право разработчикам на получение обновлений программного продукта и на
техническую поддержку
OEM (original egucpment manufacturer)-лицензия на программные средства,
которые заранее были установлены на приобретаемый компьютер. Основным
документом, подтверждающим легальность OEM-продуктов является сертификат
подлинности.
«Коробочная» лицензия предполагает приобретение пользователем коробки с
программным обеспечением, в которой должны находится лицензионное соглашение,
сертификат подлинности, регистрационная карточка, дистрибутив с программным
продуктом и книга с документами.
«Оберточная» лицензия представляет разновидность конклюедентной сделки, в
соответствии с которой лицо устанавливает правоотношения не в устной или письменной
формах, а своими действиями. Таким действием является вскрытие покупателям упаковки
экземпляра компьютерной программы.
Click wrap-лицензия используется поставщиками ПО при его распространении
через Интернет-среду.
Некоторые виды лицензирования можно рассмотреть на примере
лицензионной политики Oracle.
Для
программных продуктов Oracle существуют две различные схемы
лицензирования продуктов:
шш)
щщ)
для группы пользователей (Named User License);
для всеобщего пользования (Processor License).
Первая чаще применяется в закрытой "корпоративной" системе, где круг и число
пользователей известны заранее или могут быть оценены, вторая более применима в
Internet в случаях общедоступных (public use) систем, когда число пользователей невозможно
оценить.
Количество лицензий на опции Oracle, расширяющие его возможности и
облегчающие процесс администрирования и настройки производительности, должно
совпадать с количеством лицензий самого сервера.
Для многих продуктов предусмотрено минимальное количество лицензий, ниже
которого заказ невозможен. Так, например, минимальное количество именованных
пользователей для сервера баз данных Oracle Enterprise Edition составляет
десять
пользователей на один процессор. Это означает, что, например, на четырехпроцессорный
сервер приобретается лицензия не менее чем на 40 пользователей.
Лицензионные термины. Разнообразие продуктов Oracle предполагает разные виды
лицензирования. Для правильной оценки необходимого количества лицензий, следует точно
представлять себе, что подразумевается под каждым термином.
Named User (именованный пользователь). На пользователя лицензируется большинство
продуктов, включая серверы и средства разработки. Одна лицензия в данном случае
соответствует лицу, наделенному правами использования программы. Необходимо
подчеркнуть, что при лицензировании не принимаются во внимание технические аспекты
подключения пользователей. Так, например, число лицензий не меняется в зависимости от
того, сколько пользователей работает с программой одновременно и использованы ли
средства концентрации соединений, такие как мониторы транзакций или серверы приложений.
Общее количество заказываемых лицензий должно соответствовать максимальному
количеству сотрудников, которым необходимо работать с программой.
Processor (на процессор). В случаях, когда серверные продукты используются в
средах, где невозможно определить круг пользователей, либо их количество очень
велико, применяется лицензирование, основанное на количестве процессоров рабочей
компьютерной системы.
Per Computer (на компьютер). Лицензируемое программное обеспечение выполняется
исключительно на указанном в договоре компьютере.
Техническая поддержка. Общая стоимость контракта на приобретение продуктов
Oracle состоит из стоимости непосредственно программного обеспечения и первого года
технической поддержки. По истечении указанного срока заказчик может продлить
техническую поддержку на следующий год. В стоимость базового уровня технической
поддержки (Oracle Silver Support) входят консультации со специалистами Центра
технической поддержки по телефону и электронной почте, доступ к web-сайту технической
поддержки, а также бесплатное предоставление по запросу новых версий и исправлений
(patches) приобретенных продуктов.
В настоящее время Microsoft предлагает ряд программ корпоративного
лицензирования, правильный выбор которых позволяет свести к минимуму затраты на
управление имеющимися на предприятии лицензиями на ПО:
ыы)
Open License (MOLP);
ээ)Open License Government MOLG;
юю)
Microsoft Academic Open License;
яя)
Open Subscription Lisence (OSL);
ааа)
Multy Year Open Lisence(MYO);
ббб)
Enterprise Agreement (EA);
ввв)
Enterprise Agreement Subscription (EAS).
Все программы корпоративного лицензирования Microsoft можно подразделить на
общие и специализированные для компаний среднего и малого бизнеса (до 250
компьютеров), для крупных организаций. На первом этапе при выборе программы
лицензирования можно воспользоваться алгоритмом выбора оптимальной лицензии,
предлагаемым Microsoft (таблица 1):
Таблица 1. Алгоритм выбора оптимальной лицензии
Общие
Для компаний Для крупных
Характеристика лицензионной
среденего и
организаций
программы
малого бизнеса (>250 deskstops)
Бессрочное право на использование ПО
Open License, Multy Year Open Enterprise
L&SA,
Lisence (MYO), Agreement (EA),
SA
L&SA, SA
L&SA, SA
Подписка на использование ПО в течение
фиксированного срока, по истечении
которого клиент может продлить соглашение
или выкупить постоянные лицензии на
текущие на момент выкупа версии
продуктов
Open
Subscription
Lisense (OSL)
L&SA
Enterprise
Agreement
Subscription (EAS),
L&SA
Программы лицензирования Microsoft Enterprise Agreement (ЕА) и Microsoft
Enterprise Agreement Subscription (EAS), предназначены для организаций, планирующих
стандартизацию ПО на платформе Microsoft и имеющих не менее 250 компьютеров.
Основное отличие ЕА от EAS заключаются в том, что в первом случае организация
получает право постоянного пользования лицензиями, вторая же программа предполагает
использование приобретенного ПО лишь в течение срока действия соглашения.
Преимущества ЕА и EAS включают в себя:
1. Значительную
скидку (по сравнению с другими программами
корпоративного лицензирования) на все продукты Microsoft, учет ПО,
закупленного ранее по другим программам лицензирования.
2. Распределение стоимости программного обеспечения на 3 годовых платежа;
3. Необходимость ежегодного согласования с Microsoft только количества
добавленных за отчетный период персональных компьютеров в организации.
4. Возможность использования дополнительного ПО для предприятия по
этой же программе до его закупки.
5. Возможность использования новых версий базовых и дополнительных
продуктов.
6. Фиксация цены на срок действия контракта исходя из первоначально
заявленного коичества рабочих станций (при этом сервера не учитываются).
7. Возможности по использованию бесплатных копий дополнительных
продуктов для проведения обучения внутри организации.
ЕА и EAS упрощают управление парком имеющихся у компании лицензий, помогают
обеспечивать соответствие версий используемого ПО и, как следствие, существенно снижать
юридические, бизнес и технологические риски использования программного обеспечения.
При принятия решения о лицензировании корпоративного ПО с помощью ЕА или
EAS, заказчик напрямую заключает лицензионное соглашение с Microsoft, весь процесс
заключения договоров и оплаты требует участия LAR-партнеров Microsoft (Large Account
Reseller). Заключение соглашений ведется по двум направлениям.
1)
Соглашение между MS и заказчиком, с указанием LAR партнера: Соглашение
Microsoft Business Agreement; Соглашение Microsoft Enterprise Agreement или Соглашение
Enterprise Subscriptions Agreement; Соглашение о Регистрации предприятия через торгового
посредника Microsoft Enterprise Enrollment (indirect) или Соглашение о Регистрации
предприятия через торгового посредника Microsoft Enterprise Subscription Enrollment (indirect).
2)
Хозяйственное соглашение между заказчиком и LAR-партнером на поставку
лицензий.
Enterprise Agreement и Enterprise Agreement Subscription доступны как способы
лицензирования напрямую через Microsoft с помощью предпродажной и послепродажной
поддержки и консультаций со стороны LAR-партнеров Microsoft.
Изменения в лицензировании программных продуктов Microsoft®
Лицензия на Windows XP Pro OEM позволяет использовать вместо
лицензированного продукта любую предыдущую версию (Windows NT Workstation, Windows
2000 Pro), а также Windows 98 Second Edition.
Кроме того, в отличие от лицензионных соглашений для OEM-версий Windows 9x,
Windows ME, Windows 2000 Pro, которые в явном виде запрещают передачу ПО во
временное пользование, аренду и прокат, в лицензионном соглашении для OEM-версии
Windows XP ограничение на аренду снято.
Таким образом, компьютерные клубы и Интернет-кафе могут использовать OEMверсии Windows XP Pro и Windows XP Home Edition, и подписание каких-либо
дополнительных соглашений при этом не требуется.
Более подробная информация по лицензированию WindowsXP по адресам:
www.microsoft.com/rus/licensing/rent.html
www.microsoft.com/rus/licensing/pos.html
www.microsoft.com/rus/licensing/liceula.htm http://www.arbyte.ru/support/soft/101201 .shtml
Информационный бизнес
Информационный рынок, несмотря на разные концепции и мнения относительно
его инфраструктуры, существует и развивается, а значит, можно говорить о бизнесе
информационных продуктов, услуг, под которым понимается не только торговля и
посредничество, но и производство.
К функциям информационного бизнеса относятся:
ггг)
управление финансами и ведение учета;
ддд)
управление кадрами;
еее)
материально-техническое снабжение;
жжж)
организация производства;
ззз)
маркетинговые исследования;
иии)
лизинговые операции;
ккк)
консультационное обслуживание;
ллл)
страхование имущества и информации;
ммм)
организация службы информационной безопасности;
ннн)
сервисное обслуживание.
Правовое регулирование на информационном рынке
Развитие рыночных отношений в информационной деятельности поставило вопрос
о защите информации как объекта интеллектуальной собственности и имущественных
прав на нее. В Российской Федерации принят ряд указов, постановлений, законов, таких,
как:
ооо)
"Об информации, информатизации и защите информации"
ппп)
"Об авторском праве и смежных правах"
ррр)
"О правовой охране программ для ЭВМ и баз данных"
ссс)
"О правовой охране топологий интегральных схем"
Рассмотрим основные положения закона "Об информации, информатизации и
защите информации", который является базовым юридическим документом,
открывающим путь к принятию дополнительных нормативных законодательных актов для
успешного развитии информационного общества. С его помощью удалось частично
решить вопросы правового регулирования на информационном рынке ряда проблем:
защиты прав и свобод личности от угроз и ущерба, связанных с искажением, порчей,
уничтожением "персональной" информации.
Закон состоит из 25 статей, сгруппированных по пяти главам:
I.
Общие положения.
II.
Информационные ресурсы.
III.
Пользование информационными ресурсами.
IV.
Информатизация, информационные системы, технологии и средства их
обеспечения.
V.
Защита информации и прав субъектов в области информационных
процессов и информатизации.
В законе определены цели и основные направления государственной политики в
сфере информатизации. Информатизация определяется как важное новое стратегическое
направление деятельности государства. Указано, что государство должно заниматься
формированием и реализацией единой государственной научно-технической и
промышленной политики в сфере информатизации.
Закон создает условия для включения России в международный информационный
обмен, предотвращает бесхозяйственное отношение к информационным ресурсам и
информатизации, обеспечивает информационную безопасность и права юридических и
физических лиц на информацию. В нем определяются комплексное решение проблемы
организации информационных ресурсов, правовые положения по их использованию и
предлагается рассматривать информационные ресурсы в двух аспектах:
ттт)
как материальный продукт, который можно покупать и
продавать;
ууу)
как интеллектуальный продукт, на который
распространяется право интеллектуальной собственности,
авторское право.
Закон закладывает юридические основы гарантий прав граждан на информацию.
Он направлен на урегулирование важнейшего вопроса экономической реформы - формы,
права и механизма реализации собственности на накопленные информационные ресурсы
и технологические достижения. Обеспечена защита собственности в сфере
информационных
систем
и
технологий,
что
способствует
формированию
цивилизованного рынка информационных ресурсов, услуг, систем, технологий, средств их
обеспечения.
Ввод в действие закона, обеспечение выполнения его положений гарантируют, что
государство получит значительную экономию средств и необходимые условия для более
устойчивого развития экономики и построения демократического общества в России.
Новый ассортимент информационных продуктов и услуг
Информационный сервис в структуре общественного разделения труда развивается в
направлении расширения ассортимента и повышения качества предоставляемых
пользователям информационных продуктов и услуг.
По оценкам отечественных и зарубежных специалистов, современному
информационному сервису присущи следующие тенденции:
ффф)
персонификации максимального учета и удовлетворения
информационных потребностей конкретного пользователя;
ххх)
диверсификации - увеличение многообразия
информационных продуктов и услуг, расширения возможностей
выбора в соответствии с потребностями, вкусами и финансовыми
возможностями абонентов;
ццц)
конвергенции - стирания границ между информационными
продуктами и услугами.
В соответствии с указанными тенденциями в практике научных, научно-технических
библиотек, информационных служб и агентств растет спрос на услуги, адресуемые на
рабочее место (персональный компьютер) пользователя (например, выполненные по
конкретному запросу электронные копии журнальных статей обладают для потребителя
несомненными преимуществами в сравнении с традиционной подпиской на периодические
издания).
Диктуемая временем необходимость более полно удовлетворять разнообразные
запросы пользователей вынуждает осваивать широкий спектр информационноаналитических, образовательных, редакционно-издательских услуг, услуг удаленного
доступа и передачи информации, сочетать технологии информационного обслуживания в
локальном и сетевом режимах.
Естественное желание повысить привлекательность предоставляемых потребителям
информационных услуг заставляет работать над материальным воплощением услуги,
превращая ее в физический продукт с собственным образом и преимуществами в плане не
ограниченного во времени (а иногда и пространстве) доступа. Например:
ччч)
традиционные библиотечные услуги - выставки, просмотры
документов, дни специалиста - могут быть материализованы в
информационные продукты - дайджесты, тематические подборки,
фактографические досье;
шшш)
наряду с популярными выставками и ярмарками
инновационных проектов, научно-технических идей, продукции и
услуг получают распространение их мультимедийные версии;
щщщ)
образовательные услуги, связанные с овладением
компьютерными технологиями, обучением иностранным языкам,
повышением квалификации, подготовкой и переподготовкой
кадров, трансформированные в видео- или мультимедийные курсы,
завоевывают признание у большего числа потребителей и т.п.
Расширение ассортимента информационных продуктов и услуг в традиционной и
машиночитаемой формах порождает проблему технологической воспроизводимости новых
видов информационного сервиса. Известно, что специфика каждого отдельно взятого
информационного продукта или услуги определяется его потребительскими свойствами способностью удовлетворять конкретные запросы пользователей, весьма динамичные в
своем развитии. Именно потребительские свойства определяют спрос на конкретные
продукты и услуги, обусловливают их привлекательность и стоимость, что особенно важно,
если информация реализуется в качестве товара.
В группу потребительских свойств, как правило, включают следующие характеристики
информационных продуктов и услуг:
ыыы)
адресность информации (ориентация на конкретные
категории пользователей и целевые установки);
эээ)
временные затраты на подготовку и использование
информационного сообщения;
ююю)
оперативность предоставления информации, сроки
удовлетворения запроса;
яяя)
возможность многоаспектного поиска информации;
аааа)
надежность представленных данных (сроки их
актуализации, достоверность источников информации);
бббб)
аспектность охвата темы, проблемы в пределах основной и
смежных областей знания и практической деятельности;
вввв)
возможность машинной обработки и распространения
информации;
гггг)
компактность сообщения;
дддд)
удобство в обращении (дружественный интерфейс,
детальность пользовательских инструкций);
ееее)
доступность (по каналам связи, видам носителей, цене);
жжжж) защищенность от несанкционированного доступа и
воздействия;
зззз)
условия хранения (для информационных продуктов);
ииии)
эстетичность, современный дизайн, фирменный стиль;
кккк)
мода, престиж и др.
Для любой библиотеки, информационной службы практический интерес представил бы
сравнительный анализ потребительских свойств информационных продуктов и услуг,
конкурирующих между собой в плане удовлетворения конкретных запросов пользователей.
Например:
лллл)
услуг удаленного доступа к полнотекстовым БД,
электронной доставки документов и традиционного МБА;
мммм) создаваемых на местах локальных БД с их аналогами на
отечественном (или мировом) информационном рынках и т.п.
Список использованных источников
http://www.ksdi.ru/right/2001 57 58(9-10Vdzvaloshinskii pr_9_10.html
http://www.kcnti.ru/irr/57/l I .html
http://www.fact.ru/archiv/numO 1 /mbit.html
http://gold.4dd.ru/referats/Iook/doc-5231 -2.html
http://www.stu.ru/inform/glaves/glaval /gl_l_2.htm# 123
http://www.ikc.omgau.ru/actual/actual 1 .htm
 Тема 10.
Взаимодействие с производителями и поставщиками
аппаратного и программного обеспечения
Детальный анализ вендоров
В большинстве проектов создания информационных систем задействованы три
стороны: заказчик, производитель оборудования или программного обеспечения, а также
посредник между ними в лице интегратора. Заказчик общается с интегратором,
интегратор — с производителем, и эти два круга общения оказываются изолированы друг
от друга. Так обстоит дело при внедрении простых информационных систем, однако если
речь идет о сложных проектах, цена которых начинается с десятков тысяч долларов,
заказчик может вступить в непосредственное взаимодействие с производителем1.
Для прямой работы с вендором (производителем и поставщиком) есть две
основные причины: «Во-первых, общение заказчика с поставщиком является способом
воздействия на посредника — дистрибьютора или интегратора, а во-вторых, это способ
воздействия на самого поставщика. Вендор обычно гораздо внимательнее слушает
конечного потребителя, нежели интегратора, если тот ему рассказывает о своих нуждах:
почему, например, нужно ускорить поставку и сделать ее не за двенадцать, а за восемь
недель. Решать такие вопросы напрямую бывает эффективнее, нежели задавать их через
цепочку посредников».
Кроме того, как правило, интеграторы хорошо справляются лишь с задачами,
похожими на те, что они уже решали ранее. В случае же принципиально новых задач
непосредственное взаимодействие заказчика и производителя может стать единственным
способом преодоления временной некомпетентности местного интегратора и в конечном
итоге пойдет ему же на пользу, позволив приобрести новый опыт. И тогда наличие
регионального представительства у вендора может стать важным конкурентным
преимуществом.
Взаимодействие с производителем оборудования необходимо, потому что качество
комплектующих и цены на рынке сильно варьируются. С поставщиком можно
договориться, например, о плановой поставке техники, определить границы цен, бюджет
и т. п.
Взаимодействие с вендором имеет смысл лишь в том случае, если в компании
существует продуманная ИТ-стратегия. Основным условием ее построения, в свою
очередь, является бизнес-стратегия, в которую органично включены вопросы
централизованного финансирования ИТ. Однако последнее условие в 90% случаев не
выполняется: «Либо у руководства компании существуют смутные представления об ИТстратегии, либо у разных управляющих отсутствует согласие по поводу целей развития. А
от этого согласия зависит развитие взаимоотношений с поставщиками, будь то
консультанты, поставщики программного обеспечения или вычислительной техники.
Если ресурс, выделяемый на развитие информационных технологий, недостаточно
специфицирован и за него отвечают различные подразделения, то могут возникать самые
разные сценарии, в том числе и сценарий «дикого рынка», когда заказчик становится
ареной неупорядоченной конкурентной борьбы нескольких поставщиков (иногда,
впрочем, он специально устраивает такую борьбу с целью добиться снижения цены или
получения иных выгодных условий).
С учетом вышеизложенного выбор вендора является важной задачей
информационного менеджмента.
Детальный анализ вендоров представляет собой важный этап работы с вендорами 2.
Главная задача этого шага — тщательнейшая проработка соответствия вендорского
продукта функциональным запросам компании, проработка технических моментов
вендорского решения, а также планомерная работа с бывшими заказчиками данного
вендора с целью понять, насколько качественно вендор решил проблемы других
компаний.
Прорабатывая данные, предоставленные вендорами, необходимо рассмотреть
различиях между вендорами, так как именно эти различия и повлияют на окончательный
выбор. Обычно на конечном этапе рассматриваются два (иногда три) вендора. Эти два
Михаил Попов, Как использовать вендора, http://www.ibusiness.ru/marcet/manager/31702/,
Опубликовано 22 января 2004 года
2
Глеб Галкин, Эффективный ИТ-отдел. Как выбирать вендора. Часть 4. Детальный анализ вендоров //
Корпоративные системы, №1(111), 2005
1
вендора должны быть подвергнуты детальному анализу. Детальный анализ состоит из
двух основных частей:
 функциональность продукта, в ходе которого выясняют, насколько точно
продукт, предлагаемый вендором, соответствует функциональным запросам
компании;
 технические решения.
Функциональная часть детального анализа должна проводиться достаточно
детально. Как наиболее важная, она требует особенных аналитических усилий.
Необходимо упомянуть, что ошибки именно в этой части, как правило, являются
основным источником неприятных сюрпризов в фазе внедрения решения. Поэтому
понимание бизнес-процессов, которые надо перевести в информационные системы,
должно быть очень глубоким. Серьезные требования предъявляются и к уровню
детализации системы вендора. При выборе вендора необходимо задавать вопросы до тех
пор, пока не будет получен удовлетворительный ответ. Если в результате этой работы от
вендора начнут поступать недовольные замечания по поводу детальности вопросов,
можете принять это как комплимент хорошей работе. Жалобы подобного рода можно
использовать как индикатор правильности направления движения. Важно понять и
обратное: если вендор не жалуется, то до желаемого уровня детализации еще далеко и
процесс выбора определяется самим вендором, а не заказчиком.
Основа функциональной части детального анализа — демонстрация решения.
Эффективнее всего будет организовать для каждого вендора по две разные демонстрации.
На первой из них, открытой, вендор демонстрирует продукт так, как считает нужным.
Вторая демонстрация четко планируется менеджерами, ответственными за выбор вендора,
и дает ответы на вопросы, являющиеся высокоприоритетными функциональными
моментами компании-заказчика. Демонстрации надо организовывать именно в порядке,
указанном выше: сначала свободная презентация вендоров, потом, спустя некоторое
время, — презентация по плану, продуманному менеджерами заказчика.
Все вендоры знают наилучший способ презентовать свою продукцию. Открытая
ничем не лимитированная возможность показать продукт так, как вендоры считают
нужным, является важным шагом в работе с ними. Зная, что им были даны все шансы, они
будут удовлетворены ходом дела. Вы получаете все козыри в руки. Вы дали вендорам
сделать то, что они хотели, теперь их черед сделать то, что вам нужно. Вендоры и не
будут подозревать, что вторая демонстрация для менеджеров по выбору вендора намного
более важна.
Содержание второй демонстрации критично. Менеджеры по выбору вендора
должны представить вендору обширный список требуемых функций, а также пробные
сценарии и данные для тестовой работы системы. В результате этой демонстрации
менеджеры по выбору вендора должны понять не только то, как в данной системе
выполняются ключевые функциональные требования, но и как та или иная функция
сконфигурирована в системе и какой уровень конфигурации требуется, чтобы заставить ее
работать согласно функциональным требованиям. Менеджеры по выбору вендора ни на
минуту не должны забывать, что многоступенчатые конфигурации и настройки системы
повышают стоимость внедрения. Нужно вести учет примерного уровня настроек,
требуемого для функциональности. Вендора надо просить дать столько демонстраций,
сколько нужно, чтобы менеджеры по выбору вендора поняли в деталях, как каждая из
функций будет выполняться.
В дополнение к демонстрации основных функциональных требований менеджеры
по выбору вендора должны запросить демонстрации вспомогательных функций системы,
если относительно них остаются какие-либо вопросы после первой демонстрации. В эту
часть обычно включаются дополнительная функциональность, инструменты
конфигурации, языки настройки, интеграционные средства, API, инструменты извлечения
данных, возможности создания отчетов и другие.
Как правило, на каждую демонстрацию отводится целый день. Вторая
демонстрация назначается на одну из последующих недель. Одна-две недели после первой
демонстрации должны быть посвящены анализу откликов других заказчиков на эту же
систему и дополнительные исследования по данному вендору. Менеджеры по выбору
вендора должны иметь достаточно времени между демонстрациями, чтобы собрать
воедино все, что удалось найти. Но демонстрации надо назначать достаточно близко по
времени друг к другу, чтобы быть уверенным, что сравнение вендоров сделано
качественно. Хорошим интервалом считается один день между демонстрациями.
Добиться наилучшего порядка работы данного этапа можно, выполняя следующие
правила:
1. Вендоры должны четко представлять, чего вы ожидаете от первой и второй
демонстраций.
2. Необходимо обеспечить присутствие на демонстрации каждого члена
команды менеджеров по выбору вендора и отсутствие каких-либо других
дел в этот день.
3. Членам команды менеджеров по выбору вендора следует проявлять
активность во время сессии вопросов и ответов.
4. Демонстрации должны проходить там, где это удобно вендору, чтобы он
мог показать товар в его лучшем проявлении и не имел никаких претензий в
связи с нехваткой чего бы то ни было или техническими неувязками.
Вторая часть детального анализа — технический детальный анализ. Он необходим
для выяснения полного набора технических компонентов для всех вендорских
приложений и планируемой технической архитектуры. Технический детальный анализ,
как правило, проходит при участии технического представителя (одного или более) от
вендора, членов команды менеджеров по выбору вендора и технического специалиста из
ИТ-отдела компании. Данная часть работы предполагает, что будут определены все
необходимые технические детали будущего решения. Эта часть состоит из трех
подчастей:
 предпочтительная техническая архитектура решения;
 способность поддерживать пиковые объемы нагрузки;
 подход к разработке.
Прежде всего менеджеры по выбору вендора должны определить рекомендуемые
стандарты и вероятные требования для всех требуемых компонентов планируемой
системы. Дело в том, что показать в благоприятном свете свое решение вендорам часто
удобнее на конфигурации, минимально соответствующей требованиям. Но реальный
интерес представляет не минимальная, а наиболее вероятная конфигурация, и оценивать
решения надо относительно нее. Очевидно, что наиболее вероятная конфигурация
определяет и цену.
Менеджеры по выбору вендора могут проанализировать различные аспекты
технического анализа. Результатом работы на этом этапе должно быть четкое понимание
вероятной стоимости проекта с технической точки зрения, чтобы менеджеры могли
создавать бюджет проекта начиная с конца описываемого здесь этапа выбора вендора.
Потенциальные вопросы должны быть распределены таким образом, чтобы было понятно,
какие технологические вопросы повлияют на процесс принятия решения в целом и какие
— на общую стоимость проекта.
Список рассматриваемых вопросов может быть следующим:
1. Предпочтительная техническая архитектура решения: ОС, серверы,
клиенты, сеть, базы данных.
2. Количество и тип требуемых серверов и систем хранения.
3. Инструменты интеграции: middleware, API и т. д.
4. Приложения от третьих компаний, необходимые для работы решения
(middleware, приложения создания отчетов, базы данных и др.).
5. Минимальные требования к клиенту.
6. Требования к сети и пропускной способности между сервером и клиентом
7. Возможности балансировки нагрузки и кластеризации.
8. Подходы к созданию резервных копий данных. Управление
восстановлением данных.
9. Процедуры старта и завершения работы системы
10. Защита и аудит системы. Пользовательские и администраторские
настройки.
Вторая часть технического анализа состоит в том, чтобы оценить способность
системы поддерживать пиковые объемы транзакций и адаптироваться к будущему
изменению
бизнеса.
Здесь
важно
четко
проанализировать
возможности
масштабируемости системы. Для этого необходимо оценить текущий объем
пользователей и пиковую нагрузку на систему. Это трехступенчатый процесс. Сначала
надо определить день и время пиковой активности существующей в компании системы.
После чего взять реальный объем транзакций и количество пользователей. Должны быть
определены пики нагрузки, сезонные и месячные факторы (отчеты конца месяца или
финансовые обработки) и недельные влияния. Эти пиковые изменения зависят в
значительной степени от индустрии, типа компании, концентрации пользователей,
сезонности бизнеса и ряда других показателей.
После того как пики определены, техническая команда должна построить
календарь работы системы, описать, какие процессы в какие часы работают. Данная
таблица может выглядеть примерно так, как показано на рис. 1.
Менеджеры по выбору вендора могутт оценить количество пользователей и
объемы транзакций для пиковых и общих периодов. Затем эта информация должна быть
просуммирована, как показано на рис. 2.
После этого менеджеры могут сравнить эти данные с данными рассматриваемой
системы. Вендоры обычно представляют два различных типа показателей мощностей
системы. Один является результатом лабораторного стресс-теста, который показывает
максимальные возможности системы при определенных различных технических
условиях. Второй — результат практического внедрения системы у реального
пользователя. Во втором случае менеджеры по выбору вендора должны связаться с
компанией, у которой уже работает эта система, и проверить данные и способность
системы управляться с пиковыми объемами.
В целом все эти сборы данных и оценки должны стремиться ответить на два
вопроса.
1. Будет ли у онлайнового пользователя нормальная возможность
взаимодействовать с системой во время пиковых часов работы системы
(будет ли время ответа системы находиться в приемлемых пределах для
пользователей, или ответ будет слишком медленным)?
2. Будет ли система способна обработать всю требуемую информацию в какоето разумное время?
Наконец, последняя составляющая технического детального анализа — оценка
методологии разработки и технологий, использованных вендором для создания данной
системы или продукта. Эти два фактора влияют на стоимость системы. Вендоры, которые
сделали инвестиции в специальные технологии и методики создания приложений, такие
как SDLC, CMM, или вендоры с сертификатами качества ISO имеют важные
преимущества. Чем более распространена технология, использованная при создании, тем
выше доступность рабочей силы и тем, как правило, ниже стоимость продукта. Можно
оценить уровень адаптации сертификации и методологий через контакт с компанией,
которая выдала сертификат. Можно также, например, попросить вендора показать
руководство по стандартам разработки.
В области технического детального анализа один вендор редко отличается от
другого. Большинство вендоров поддерживают все технологии, присутствующие на
рынке, используют одинаковые среды разработки, обеспечивают похожие интерфейсы и
поддерживают объемы передачи данных, превышающие ожидаемые пики. Поэтому
технический детальный анализ должен быть сосредоточен на понимании потенциальной
стоимости внедрения данной системы с точки зрения аппаратной и инфраструктуры.
Следует предусмотреть и страховку от любых сюрпризов, в особенности связанных с
поддержкой платформ и масштабируемостью решения анализа.
Тем не менее фаза технического детального анализа необходима. Важно понять:
при таком подходе, а также при проведении двух функциональных презентаций команда
по выбору вендора держит контроль над ситуацией в своих руках, что и требуется делать
явно или скрыто на протяжении всего периода выбора.
Проверка примеров и анализ несоответствий3
Последняя часть работ, связанная с детальным анализом вендоров, — это анализ
примеров успешных проектов вендора, общение с клиентами вендора, а также анализ
несоответствий и выбор вспомогательных поставщиков.
Проверка примеров успешных проектов вендора дает два преимущества. Вопервых, можно независимо проверить степень верности данных предоставленных
вендором на этапе детального анализа. При общении с клиентами вендора, как правило,
обнаруживаются всевозможные факты, которые обычно не упоминаются в прямом
разговоре. В результате можно избежать многих ошибок, которые были допущены
Глеб Галкин, Эффективный ИТ-отдел. Как выбирать вендора. Проверка примеров и анализ
несоответствий // Корпоративные системы, №2(112), 2005
3
другими. Во-вторых, звонки в другие компании по поводу данного вендора
устанавливают отношения с ИТ-отделами других компаний, что впоследствии может
привести к продуктивному обмену опытом, коллективной работе с вендорами и так далее.
Если такие отношения закрепляются, то обе компании получают преимущество во
влиянии на вендора.
Источники информации
Процесс выбора вендора предусматривает, что он должен предоставить
менеджерам заказчика список клиентов с реализованными проектами, которые наиболее
близки к проекту заказчика. Этот список должен быть структурирован по типу компании,
размеру, технической платформе, планируемому продукту, объему производства или по
географическому признаку. Другой источник информации, важность которого трудно
переоценить, — это компании, являющиеся клиентами данного вендора, но не
упомянутые вендором. Ни в коем случае нельзя ограничиваться выданным самим
вендором списком компаний-клиентов. Иначе понимание командой менеджеров выбора
реальных недостатков вендора будет ощутимо искажено. Такая информация выводит
вендора «на чистую воду» и показывает реальное положение вещей. Это один из наиболее
ценных подходов в плане добычи альтернативных мнений о данном вендоре.
Основные пути вычисления клиентов, не упомянутых вендором, следующие.
Сообщения на сайтах поиска/предложения работы. Логика данного хода проста:
компании, которые нанимают людей и указывают в списке необходимых навыков
технологию данного вендора, скорее всего имеют эту технологию в производстве. Опрос
специалиста, указавшего данную технологию в списке навыков, которыми он владеет,
тоже может привести к очень продуктивным результатам. Есть только одно неудобство —
не все технические специалисты работали с данными продуктами на производстве, многие
лишь ознакомились с ними в лабораторных условиях.
Любая компания, занимающаяся трудоустройством в секторе ИТ, за определенную
плату сможет выдать достаточно полную информацию о компаниях, использующих
данную технологию, на базе резюме и предложений проходивших через них.
Таким образом, у команды менеджеров по выбору вендора появляется мастерсписок клиентов вендора. В зависимости от размера проекта количество компаний из
обоих списков, которым необходимо звонить, колеблется от двух до восьми из каждого
списка. Необходимо помнить, что компании из вендорского списка отличаются тем, что
скорее всего подготовлены вендором и готовы ответить на вопросы.
Вопросы клиентам вендора
Как правило, специалисты рекомендуют разговор по телефону члена команды
менеджеров по выбору вендора с CIO, ИТ-директором или сотрудником, им назначенным.
Если можно провести это интервью в очном общении — это лучше. Не бойтесь тратить на
эту стадию время менеджеров команды выбора вендора. Этот этап, по сути, является
последним препятствием, которое вы воздвигли на пути нерадивых вендоров к вашим
деньгам. Это ваша последняя линия обороны и последнее наступление.
Список вопросов, которые команда менеджеров по выбору вендора должна
задавать, несколько отличается в каждом конкретном случае. Очень важно также
позволить интервьюируемому клиенту вендора открыто говорить на любую интересную
ему тему. Опыт показывает, что много интересной информации, как правило, приходит
именно с той стороны, с которой не ожидаешь. Вот ориентировочный список вопросов.
1. Какой продукт вы подвергали оценке?
2. Каковы были ключевые критерии выбора при принятии решения?
3. Какие функции считались критически важными, и как проходил
функциональный анализ продукта? Какова была логика распределения
приоритетов? Что было более важным, что менее важным?
4. Когда было принято решение по поводу данного продукта? Сколько
времени было потрачено на оценку вендора?
5. Какие модули или продукты были в конце концов приобретены или
внедрены?
6. Работала ли техническая архитектура так, как было запланировано?
7. Каковы именно были ключевые эффекты внедрения вендорской технологии:
снижение стоимости, увеличение оборота? Каким образом были получены
эти преимущества?
8. Какой период потребуется или потребовался, чтобы получить прибыль от
внедрения данной технологии?
9. Были ли какие-либо технические проблемы или проблемы поддержки
пользователей? Как вендор справился с этими проблемами? Вмешательство
какого уровня руководства потребовалось для разрешения данной
проблемы?
10. Прибегали ли к помощи поставщиков ИТ-услуг при внедрении данного
продукта или технологии?
11. Каково качество услуг вендора после продажи?
12. Как архитектура системы вела себя по мере изменения объема транзакций и
количества пользователей?
13. Какие были сюрпризы — хорошие и плохие?
14. Какие уроки вы извлекли в результате процесса выбора и последующего
внедрения продукта вендора? Пошли бы вы на внедрение этого продукта
еще раз?
Анализ несоответствий
Анализ несоответствий, часто называемый Gap analysis, является необходимым
этапом в выборе вендора. Цель данного анализа — оценить соответствие или
несоответствие возможностей продуктов вендора, рассматриваемых на этапе детального
анализа, функциональным требованиям компании. Набор требований, которые
предъявляла компания, собирающаяся внедрить данный продукт, уже были собраны и
разложены по приоритетам. Последующие стадии работы команды выбора вендора
показали наличие или отсутствие запрашиваемой функциональности в продуктах
вендоров. В рамках анализа несоответствий команда выбора вендора должна, во-первых,
дополнительно подтвердить, что продукт данного вендора хорошо соответствует каждому
требованию, в особенности высокоприоритетным требованиям. И, во-вторых, для каждого
приоритетного требования команда выбора вендора должна оценить усилия,
необходимые, чтобы компенсировать недостаток функциональности. Как правило, именно
эти недостатки и вызывают самые крупные финансовые затраты на стадии внедрения
продукта. Каждое требование, которое команда идентифицировала в предыдущем этапе,
может быть оценено как недостаток в
зависимости от того, как вендорская система
справляется с данной проблемой.
В самом простейшем случае анализ
несоответствий выглядит так, как показано на
рисунке . Поле проблем, подверженных
анализу несоответствий, образуется степенью
важности
функциональных
требований
компании и степенью соответствия им
стандартной
версии
системы
(без
кастомизации). Полученные четыре квадрата
(в сложных случаях поле может быть
разделено на большее количество областей)
показывают нужную картину. Самый сложный случай — левый верхний квадрат.
Требования в остальных квадратах или не настолько важны для бизнеса (в связи с чем
бизнес примет эффективные по цене меры к устранению этих несоответствий), или могут
быть покрыты минимальной кастомизацией. А вот для каждого требования попавшего в
левый верхний квадрат потребуется одно из двух — кастомизация продукта или
изменение соответствующего бизнес-процесса и требований, а чаще всего сочетание того
и другого. Чаще всего для бизнес-процессов высочайшего приоритета решение
перекладывается на вендора. Процессы более низкого приоритета допускают внесение
частичных изменений в бизнес-процессы компании и частичной доводки продукта
вендора.
Как правило, для всех процессов этого квадрата составляется специальная таблица,
которая включает в себя описание сути несоответствия, описание возможного метода его
устранения, оценку усилий покрытия несоответствия и время устранения несоответствия.
Этот анализ может и должен быть сделан вместе с вендором. То, что откроется команде
выбора вендора в процессе анализа несоответствий, — это именно те неприятные
сюрпризы на стадии внедрения решения, которые приводили к срыву проекта или
существенному увеличению его стоимости. В связи с этим для команды выбора вендора
важно максимально задокументировать все обнаруженные несоответствия. Поскольку, по
сути, это анализ неспособности вендорского решения покрыть те или иные
функциональные требования, вендоры чаще всего препятствуют его проведению. Тем не
менее, команда выбора вендора должна настойчиво продолжать задавать важные вопросы,
пока не достигнет полной ясности в этом отношении.
После того как результаты анализа несоответствия получены, необходимо понять
общий уровень кастомизации, который требуется, чтобы покрыть все поле требуемых
функций. Если уровень требуемой кастомизации достаточно высок (более чем одна треть
модулей требует кастомизации или несколько критически важных модулей требуют
серьезной доработки), данное вендорское решение начинает терять привлекательность.
Кастомизация сильно увеличивает стоимость внедрения решения и постоянной
поддержки, а также лишает смысла приобретение типового стандартного решения.
Команда выбора вендора в этом случае или отказывается от данного решения, или
пересматривает выбор в пользу другого вендора.
Таблица. Детальный анализ наиболее критичных несоответствий.
Возмож Дополните Дополни
№в
Время
Функцион
Описание ный
льные
тельные Изменение
списке
устранения
№ альная
несоответс метод затраты на собствен стоимости
требован
несоответс
область
твия
устране консультан ные
продукта
ий
твия
ния
тов
затраты
1
2
Выбор сопутствующих вендоров
Если решение вендора требует дополнительного аппаратного обеспечения для
успешного внедрения, менеджеры команды выбора вендора можут столкнуться с еще
одним процессом выделения поставщика сопутствующих решений. В целом этот процесс
должен управляться согласно модели, предложенной в данном цикле. Чаще всего, однако,
не приходится проходить весь процесс отбора с нуля. Чаще всего выбор сопутствующих
вендоров сильно зависит от выбора вендора по основному решению. Отправной точкой
для выбора сопутствующего поставщика могут быть рекомендации самого вендора и
звонки по клиентам вендора. Как правило, другие клиенты этого вендора без проблем
говорят, какие компании они используют в качестве поставщика аппаратного и
дополнительного программного обеспечения, а также ИТ-услуг.
Наиболее часто встречающаяся задача — выбор поставщика оборудования под
бизнес-приложение. Необходимо опрашивать клиентов с аналогичными профилями
конфигурации и объемами обработки (пиковые и средние объемы). Для аппаратного
обеспечения эти два показателя играют более важную роль, чем сходство бизнес-моделей
компаний. Вот несколько вопросов, которые команда выбора вендора должна выяснить в
процессе выбора вспомогательного поставщика аппаратного обеспечения.
Качество юстировки решений. Как правило, серьезные бизнес-приложения
подвергаются тестированию на оборудовании ведущих вендоров. Более того,
оборудование определенным образом «затачивается» под приложения, равно как и
приложения под оборудование. Отклики клиентов помогают оценить качество связки
«вендор—вендор», а также понять, какие проблемы возникают в связи с интеграцией
систем.
Надежность и поддержка. Для критически важных приложений аппаратное
обеспечение должно поставлять достаточную степень надежности, необходимую степень
избыточности ресурсов и качественные и быстрые услуги по поддержке.
Апгрейд. Если требования масштабируемости системы предполагают ее
расширение в будущем, поставщики аппаратного обеспечения должны объяснить
принципы минимизации полной стоимости решения и нейтрализации сложностей
апгрейда.
Цена. Вендоры должны представить цену для различных уровней. Часто
поставщики приложений имеют контракты с поставщиками аппаратного обеспечения и
таким образом получают скидки, недоступные для несвязанных сделок.
И последнее, о чем стоит напомнить. В течение всего периода работы с
поставщиками команда менеджеров по выбору вендора должна делиться информацией с
ними. Часто команда менеджеров по выбору вендора не хочет выдавать информацию
вендорам, что вносит много непонимания в общение. Однако опыт показывает, что этого
делать не следует. Определенная открытость не только не повредит компании, но и
поднимет ее престиж в глазах вендора. При этом понятно, что команда выбора вендора не
должна выдавать конфиденциальную информацию, которая может повредить компании.
ИТ-услуги от вендора
Одновременно с выбором вендора команда менеджеров по выбору вендора должна
исследовать возможность использования услуг ИТ-консультантов вендора или
необходимость увеличения штата. Оба подхода в настоящее время используются
компаниями.
Опыт консультантов вендора. Готов ли вендор предоставить информацию по
проекту с аналогичными параметрами (размер компании, внедренные модули, бюджет
проекта, бизнес-модель) и запрашиваемыми услугами? Участвовали ли консультанты
вендора в других подобных проектах? Предоставит ли вендор потенциальный рабочий
план, который демонстрирует детальное понимание ключевых проблем для проекта?
Штат. Готов ли вендор предоставить информацию по каждому члену команды,
которая будет участвовать в проекте? Готов ли вендор предоставить резюме на каждого
участника команды? Имеет ли заказчик право наложить вето на участие в проекте тех или
иных членов команды?
Фиксированная цена. Готовы ли консультанты вендора заключить контракт с
фиксированной ценой? Ведь если команда выбора вендора завершила работу над
детальным рассмотрением вендоров на достаточном уровне, большинство сложностей и
недочетов уже задокументированы и понятны. В этой ситуации объем работ известен, и
вендор должен пойти на контракт с фиксированной ценой.
Скидки. Готов ли вендор предоставить скидки на услуги ИТ-консультантов,
основанные на общем объеме оплат по проекту?
Анализ политики обновлений
Есть одна важная деталь, о которой часто забывают при выборе вендора
критического бизнес-приложения. Это анализ политики обновлений ПО. Команда
менеджеров по выбору вендора должна провести анализ поставленной вендором
информации по выпуску обновлений, патчей и следующих релизов для продуктов,
находящихся в поле интереса компании. В типичном случае вендоры приложений
выпускают новый релиз системы каждые 12—18 месяцев. У вендоров, чьи релизы
планируются более чем через 18 месяцев, возможно, возникли проблемы с продвижением
их продукта на рынок.
Вендор должен предоставить и детальное описание планируемого расширения
функциональности. Если команда разработчиков вендора работает согласно какому-то
плану, то должна быть его часть, которая выдается по требованию потенциального
заказчика. Это обязательное условие, несмотря на возможные заявления вендора о
конфиденциальности запрашиваемой информации. Дело в том, что обычная практика
вендоров приложений — заставить клиента платить за новую функциональность, которая
должна была быть включена в новый релиз уже приобретенного приложения и получена
клиентом в рамках обычной поддержки.
План внедрения, финансовый анализ, переговоры4
План внедрения
Составление первичного плана внедрения вендорского решения — стандартный
шаг после проведения детального анализа возможных вендоров и анализа несоответствия.
В большинстве случаев он делается уже для одного вендора-финалиста. Цель данного
этапа — окончательно продемонстрировать полное понимание командой менеджеров всех
тонкостей и особенностей окончательного решения, а также будущих проблем. План
внедрения должен освещать и описывать следующие моменты.
1. Рабочие задачи. Прежде всего необходимо построить иерархию задач и
подзадач, выполнение которых требуется для успешного завершения проекта.
Оптимальный способ построения иерархического дерева — разбить весь проект
внедрения на пять—десять основных задач, после чего каждую задачу разбить еще на
пять—десять подзадач, пока не будет достигнут необходимый элементарный уровень
подзадач.
2. Последовательности и зависимости. В целом план внедрения должен
представлять собой порядок, в котором задачи будут выполняться. План должен четко
определять, какие функции, модули и прочие элементы вендорского решения должны
быть внедрены на каждом уровне. Кроме того, план должен показывать, какие документы
создаются на каждом этапе и как документы одной подзадачи связаны с документами
последующей. Выделение и описание основных ступеней выполнения проекта и
ключевых моментов в плане облегчает дальнейшую задачу измерения прогресса проекта.
3. Расписание и длительность выполнения задач. Должны быть определены даты
начала каждого существенного этапа выполнения проекта, а также длительность решения
каждой из задач и подзадач. План должен четко показывать время поставки, инсталляции,
конфигурирования аппаратного, программного обеспечения или других компонентов,
поставляемых вендором.
Глеб Галкин, Эффективный ИТ-отдел. Как выбирать вендора. Шаг последний: план внедрения,
финансовый анализ, переговоры // Корпоративные системы, №3(113), 2005
4
4. Ресурсы. В плане должны быть описаны количество ресурсов и набор навыков,
необходимые для завершения каждой задачи. Для каждого ресурса должно быть
определено, наружный он или внутренний. Это важный момент, так как эти данные будут
главной составляющей расходов на оплату труда по проекту.
5. Планы перевода персонала на новую систему. Эти планы показывают, как
система будет внедрена на уровне пользователя. Обычно план перевода персонала на
новую систему организуется вокруг отделов, предприятий, географических регионов или
других способов организации пользователей в компании, что облегчает обучение и
снижает степень зависимость бизнеса от перехода на новую систему.
6. Обучение. План внедрения должен показывать количество и тип конечных
пользователей, которые требуют обучения вместе с подсчетом количества часов,
необходимых для этого на каждого пользователя, и плана организации и управления
процессом обучения (тип обучения, место обучения, подбор инструкторов и т. д.).
Данный план представляет собой только предварительную основу для реального
плана, согласно которому будет происходить выполнение проекта, и он должен быть
составлен так, чтобы избежать усложнений и избыточной детализации. Например, опыт
показывает, что задачи, измеренные в часах или даже днях, будут чересчур большим
уровнем детализации. Как правило, план данного уровня должен отражать основные
этапы, измеряемые неделями, в некоторых случаях — месяцами. На данном этапе не
следует прибегать и к использованию специальных программных средств планирования
проектов. ИТ-директор должен следить за тем, чтобы команда менеджеров по выбору
вендора не попала в эту ловушку. Первый набросок делается в электронных таблицах или
в программах обработки текстовых документов. Зависимость от программ планирования
часто показывает, что команда менеджеров по выбору вендора не понимает четких этапов
проекта и пытается прикрыть это непонимание формальным структурированием.
Экономическая переоценка проекта
Стоимость работ по покрытию функциональных несоответствий запросов
компании и вендорского решения — основной пункт финансовых затрат. После того как
сделан анализ несоответствия, большинство информации, влияющей на общую стоимость
проекта, уже собрана. Самое время приступить к экономической переоценке всего
проекта. Команда может на новом витке пересчитать затраты/прибыли проекта.
Существует три источника новой информации, которую надо учесть.
1. Новое представление о затратах на оплату труда приглашенных и внутренних
специалистов вместе с оценкой количества и их почасовой стоимости.
2. Подробная информация о стоимости продукта. Вендор как минимум должен
предоставить список цен на данный продукт или технологию вместе с объяснением
ключевых моментов, которые влияют на цену, — серверы, число пользователей,
процессоры и прочее. Отметим, что это информация о стоимости до проведения
финальных переговоров с вендором о цене.
3. Предварительная оценка необходимого аппаратного и сопутствующего
программного обеспечения. В процессе детального анализа собрано достаточно
информации, чтобы можно было оценить дополнительное программное и аппаратное
обеспечения требуемое для проекта. Точно также как и в случае со стоимостью
программного обеспечения эти цифры основаны на данных, предоставленных вендором, и
будут находиться на допереговорном уровне.
В результате экономического анализа команда менеджеров по выбору вендора
должна вывести следующие параметры проекта.
Стоимость проекта. Общая стоимость приобретения всех необходимых
технических компонентов, стоимость их полной конфигурации, настройки, интеграции,
внедрения, обучения персонала и ввода системы в действие — все на основе
предварительного плана проекта.
Стоимость поддержки. Оценка необходимых годовых выплат вендору за
техническую поддержку всех технологических компонентов, будь то аппаратные или
программные.
Дополнительные издержки. Оценка любых дополнительных издержек,
возникающих в организации в самых различных категориях, например, возрастание
расходов на оплату труда (дополнительный персонал, различные дополнительные
выплаты специалистам по внедряемой технологии и затраты на мотивационные схемы),
новые потребности в производственных мощностях или оборудовании.
Ускорение амортизации. Опыт показывает, что некоторые проекты приводят к
преждевременному устареванию существующих ИТ-систем. В этом случае обесценивание
капитала, который был заложен в прошлую систему, должно оцениваться как затраты на
внедрение новой системы.
Экономический анализ также должен быть основан на разбитии стоимости проекта
на традиционные категории: аппаратное, программное обеспечение, сотрудники а также
возможные отклонения от первоначальной оценки затрат после внедрения проекта.
Конкретные суммы и всевозможные детали должны быть обсуждены совместно с
финансовым отделом или CFO. Экономический анализ может быть упрощен за счет
введения допущений там, где есть недостаток информации. После того как проект и
постоянные затраты вновь оценены, команда может пересчитать ROI проекта, время, в
течение которого проект окупится, и другие аналогичные метрики.
На этом этапе вендор и дополнительные поставщики, если таковые необходимы,
должны быть окончательно определены. Документ, представленный на рассмотрение топменеджменту компании, должен включать в себя все элементы планируемого проекта за
исключением окончательной стоимости проекта, которая будет результатом переговоров с
вендором. После утверждения этих документов руководством начинается процесс ведения
переговоров с вендором.
Обрати внимание:
1. На поддержку. Команда менеджеров по выбору вендора должна
внимательно изучить лицензии, которые будут закреплены контрактом.
Часто вендоры приложений не позволяют переназначение лицензий. Это
может стать источником проблем, если ИТ-директор решит отдать на
аутсорсинг третьим компаниям часть поддержки приложений. Более того,
бывают контракты, в которых ИТ-директор обязан оплачивать поддержку
даже в случае ее плохого качества.
2. На ограничение ответственности. Обычно, заключая контракт, вендоры
пытаются ограничить свою ответственность до размеров, покрываемых
страховками. Эта ответственность, как правило, даже в первом
приближении не покрывает потери бизнеса в том случае, если что-то
начинает идти не так. ИТ-директор должен найти способ расширить рамки
ответственности вендора.
Переговоры
Прежде чем мы приступим к изложению особенностей и тактик ведения
переговоров, надо еще раз напомнить мысль, уже высказанную ранее: менеджеры по
продажам вендора ведут переговоры и заключают сделки каждую неделю. ИТ-директор,
как правило, не имеет такого опыта. Именно поэтому ИТ-директора впадают в одну и ту
же ошибку — спрашивают о скидках на различные части проекта весьма робко. Ни в коем
случае нельзя вести себя робко. Это принципиально противопоказано. Случаи, когда была
упущена возможность получить, например, 10% скидку на весь проект при условии
осуществления немедленной сделки, к сожалению, неоднократны. Переговоры для того и
ведутся, чтобы договориться о цене и только о цене. Все остальные вопросы вы уже
выяснили ранее. Переговоры — это искусство, многоплановая игра. Грамотно играя в нее,
ИТ-директор вызовет только уважение к себе. Ниже мы приводим 10 принципов
успешных переговоров.
Цикл и задачи некоторых пунктов переговоров с вендорами
Пункт
переговоров
Цели и задачи
Естественно, нужно получить насколько можно низкие цены на все что
можно. Типичные размеры скидок находятся в пределах от 10 до 30%.
Кроме того, надо пытаться максимально оттянуть окончательные
Лицензирование
выплаты по проекту. В типичном случае при подписании платится 50%
стоимости договора. Лучше, если часть выплат происходит по
прошествии по крайней мере 90 дней после запуска системы.
На стадии подписания договора и выплаты первого взноса у
Скидки на
покупателя больше всего возможностей выторговать что-то еще.
будущие покупки Значит, именно в это время должны быть оговорены уровни скидок на
потенциальные покупки в будущем.
Надо понять, как устроена иерархия сервиса вендора. Как правило, она
Уровни сервиса и состоит из "серебряного", "золотого" и "платинового" уровней. Если
поддержки
переход из одной категории в другую предполагает определенные
выплаты, надо попытаться договориться, чтобы это было бесплатно.
Услуги
консультантов
Вендоры, как правило, подталкивают покупателей к включению в
контракт определенных услуг консультантов, чтобы быть уверенным в
том, что инсталляция решения проходит успешно. Если необходимо
дать какие-то обязательства по этому вопросу, надо принимать
уровень обязательств настолько низкий, насколько это возможно. Его
всегда можно в дальнейшем увеличить. При этом лучше
предварительно договориться о цене на услуги консультантов как на
текущий период, так и на будущее, пока контракт еще окончательно
не подписан. Цену на услуги консультантов желательно
зафиксировать в контракте.
Обучение
Типичная структура цен на обучение зависит от цены на одного
обучающегося. Поэтому вендоры пытаются связать скидки на
обучение с количеством обучающихся. Но опыт показывает, что
затраты на обучение можно снизить как минимум на 10%, независимо
от количества участников. Эффективный способ управлять
стоимостью расходов на обучение — подготовка собственного
инструктора по технологии вендора и эту возможность тоже надо
согласовать.
Будущее обучение
Желательно договориться о скидке на все будущие обучения на стадии
переговоров с вендором, пока контракт еще не подписан.
Стоимость
поддержки —
первый год
Этот компонент может заметно влиять на общую стоимость проекта.
Как правило, стоимость поддержки в первый год может составлять от
8 до 30% стоимости лицензий. Здесь надо договориться, чтобы
стоимость поддержки базировалась на проценте от цены со скидкой, а
не от прейскурантной.
Ежегодная
поддержка
Тут тоже можно попробовать сэкономить. Ключ в том, чтобы понять,
какая цена является базовой для определения процента,
затрачиваемого на ежегодную поддержку после первого года, —
стоимость лицензий или общая цена услуг за год.
Тактика ведения переговоров
Принцип № 1. Будь уверен. Надо быть твердо уверенным, что вендор вынужден
подписать контракт. Вендор вложил много времени в процесс общения с вами. Логично
полагать, что в связи с большим количеством вложенных в проект ресурсов он должен
как-то подписать договор. Это дает существенный перевес.
Принцип № 2. О стоимости каждой позиции надо договариваться отдельно.
Вендоры часто добиваются высокой общей стоимости проекта за счет того, что
завязывают несколько компонентов в пакет, который и двигают через все стадии
переговоров. Возможности вендора затемнить реальную стоимость проекта увеличивается
в том случае, если лицензирование, поддержка, аппаратное обеспечение, кредитные
линии, услуги консультантов, обучение, будущие скидки и десятки других моментов
обсуждаются совокупно как пакет. Необходимо обсуждать каждый момент отдельно,
начиная с наиболее дорогостоящего.
Принцип № 3. Не доводи подход «все из одних рук» до абсурда. Вендоры чаще
всего предлагают полный пакет услуг в дополнение к решениям, о которых идут
переговоры. У них есть преимущество в предложении услуг и обучения, однако ИТдиректор должен по-прежнему рассматривать возможные услуги конкурентов в этой
области, чтобы убедиться, что ему дается лучшая услуга по лучшей цене. Результатом
переговоров может быть принятие всего спектра услуг от одного поставщика, но переход
к такому решению на ранних этапах переговоров приводит к существенной потере
позиций.
Принцип № 4. Используй уступки. Стандартная техника переговоров состоит в
том, чтобы проанализировать позиции противоположной стороны и выявить моменты,
которые только звучат внушительно, но при этом не представляют собой особого
финансового интереса. Вы ведете переговоры по этим позициям, идете на уступки, после
чего начинаете переговоры по интересующей вас позиции и требуете в ответ уступок себе.
Однако этот принцип надо использовать осторожно, потому что вендор может
согласиться с вашими уступками и при этом не уступать в том, что вы планировали
выторговать. Кроме того, часто вендор стремиться повернуть потери и уступки заказчику
в одной части проекта в выигрыш на другой части проекта. В связи с этим ИТ-директор
должен придерживаться четкой стратегии при переговорах по каждой позиции и ставить
точку после каждого этапа переговоров, не позволяя вернуться назад.
Принцип № 5. Плохой и хороший. Необходимо назначить менеджера, который с
самого начала переговоров о цене будет играть роль отрицательного героя. Как
показывает опыт, в некоторых случаях он просто необходим. Чаще всего на такую роль
подходит CFO.
Принцип № 6. Подгадай время. Переговоры по поводу цены могут продолжаться
долго, но время играет на руку ИТ-директору. Он должен жестко контролировать
расписание и продвижение переговоров. Как и все компании, поставщики программных
аппаратных и услуг находятся под давлением годовых, квартальных и месячных планов
продаж. Максимальный эффект может быть достигнут в последней четверти и в конце
финансового года в связи с тем, что вендор пытается достичь наилучших результатов по
итогам года.
Принцип № 7. Держи в поле зрения по крайней мере двух вендоров. До
финального подписания контракта необходимо продолжать думать об альтернативном
вендоре. Если основной вендор почувствует что переговоры с ним не имеют никакой
альтернативы, ИТ-директор существенно потеряет вес на переговорах. Кроме того,
возможно, что под впечатлением от переговоров второй вендор пойдет на более
оптимальные условия и тем самым выдвинет свою кандидатуру на основную позицию.
Принцип № 8. Никогда не вноси предоплату за поддержку. Иногда вендоры
предлагают скидки в случае, если заказчиками вносится предоплата за поддержку ИТсистемы. На эту уловку ни в коем случае нельзя идти, так как ИТ-менеджер теряет
возможность влияния на вендора. Риск потери предоплаты, как правило, гораздо выше,
чем процент, выигранный на скидке.
Принцип № 9. Знай, когда «раствориться». Если переговоры заходят в тупик, то
один из приемов — уйти в тень, затаиться — под любым предлогом временно не отвечать
на письма и телефонные звонки менеджеров вендора. Время на стороне покупателя, и
недостаток информации будет оказывать давление на вендора, может дать ощущение, что
покупатель «ускользает», а это даст дополнительные преимущества.
Принцип № 10. Последняя уступка. Практика переговоров вскрыла еще одну
интересную особенность. После того как достигнуто соглашение по поводу цен, условий и
прочего, ИТ-директор должен иметь в кармане еще одно последнее условие. Как правило,
вендор соглашается с этим последним условием взамен на то, что менеджер подпишет
контракт немедленно после получения требуемой уступки.
И еще один совет напоследок. Не нужно прекращать общение с клиентами
рассматриваемого вендора. Информация от других потенциальных и реальных клиентов
вендора может улучшить понимание способов ведения переговоров и областей, в которых
вендор готов идти на уступки.
10 принципов успешных переговоров с вендором
№ 1. Будь уверен.
№ 2. О стоимости каждого позиции надо договариваться отдельно.
№ 3. Не доводи принцип «все из одних рук» до абсурда.
№ 4. Используй уступки.
№ 5. Плохой и хороший.
№ 6. Подгадай время.
№ 7. Держи в поле зрения по крайней мере двух вендоров.
№ 8. Никогда не вноси предоплату за поддержку.
№ 9. Знай когда «раствориться».
№ 10. Последняя уступка.
Хорошо налаженная процедура выбора вендора — один из важнейших показателей
качества работы ИТ-директора и ИТ-отдела в целом. По вашим вендорам будут судить о
вас. Описанная нами методология выбора вендора неопровержимо свидетельствует —
каждая компания имеет ту систему и того вендора, которых она заслуживает
ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ
РОСТОВСКИЙ ГОСУДАРСТВЕННЫЙ ЭКОНОМИЧЕСКИЙ УНИВЕРСИТЕТ «РИНХ»
Долженко А.И., Тимченко Н.А.
ИНФОРМАЦИОННЫЙ МЕНЕДЖМЕНТ.
Моделирование бизнес-процессов
Методические рекомендации по выполнению
лабораторных работ
РОСТОВ-НА-ДОНУ, 2006
УДК 004.4 (075)
Д
Долженко А.И., Тимченко Н.А. Информационный менеджмент.
Моделирование бизнес-процессов: Лабораторный практикум/ РГЭУ
«РИНХ» - Ростов-н/Д., 2006. – 102с. - ISBN 5–7972–
В лабораторном практикуме приведены необходимые теоретические
сведения и примеры моделирования бизнес-процессов с использованием
структурного подхода при проектировании информационных систем,
базирующегося на стандартах IDEF0, DFD и IDEF3. Лабораторные работы
охватывают основные этапы описания бизнес-процессов и реинжиниринга
бизнес-процессов.
Данный лабораторный практикум предназначен для студентов,
обучающихся по специальности 080801 «Прикладная информатика (по
областям)», а также может быть рекомендована для студентов специальности
080507 «Менеджмент» и аспирантов соответствующих специальностей.
Рецензенты: Ефимов Е.Н., Щербаков С.М.
Утверждён в качестве лабораторного практикума редакционноиздательским советом Ростовского государственного экономического
университета.
ISBN
 - РГЭУ «РИНХ», 2006
 - Долженко А.И., 2006
 - Тимченко Н.А. 2006
СОДЕРЖАНИЕ
С
.
ВВЕДЕНИЕ .............................................................................................................. 131
1 ЛАБОРАТОРНАЯ РАБОТА. 1 ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА
BPWIN 4.0 ........................................................................................................... 132
1.1
1.1.1
1.1.2
1.1.3
1.1.4
1.1.5
1.1.6
1.2
1.3
Общие сведения ................................................................................................................. 132
Общее описание интерфейса BPwin 4.0 .......................................................................... 132
Создание новой модели .................................................................................................... 133
Работы (Activity) ................................................................................................................. 134
Стрелки (Arrow) ................................................................................................................. 136
Установка цвета и шрифта объектов ............................................................................... 138
Model Explorer - навигатор модели .................................................................................. 139
Задание на выполнение лабораторной работы ............................................................... 141
Вопросы для самопроверки .............................................................................................. 142
2 ЛАБОРАТОРНАЯ РАБОТА. 2 СОЗДАНИЕ ДИАГРАММЫ
ДЕКОМПОЗИЦИИ ............................................................................................. 146
2.1
2.1.1
2.1.2
2.2
2.3
Общие сведения ................................................................................................................. 146
Диаграммы декомпозиции ................................................................................................ 146
Стрелки на диаграммах декомпозиции ........................................................................... 149
Задание на лабораторную работу..................................................................................... 155
Вопросы для самопроверки .............................................................................................. 162
3 ЛАБОРАТОРНАЯ РАБОТА 3. СОЗДАНИЕ ДИАГРАММЫ УЗЛОВ ....... 163
3.1
3.1.1
3.1.2
3.2
3.3
Основные сведения ........................................................................................................... 163
Диаграммы дерева узлов ................................................................................................... 163
Диаграммы FEO................................................................................................................. 165
Задание на лабораторную работу..................................................................................... 166
Вопросы для самопроверки .............................................................................................. 167
4 ЛАБОРАТОРНАЯ РАБОТА 4. РАСЩЕПЛЕНИЕ И СЛИЯНИЕ
МОДЕЛЕЙ .......................................................................................................... 168
4.1
4.1.1
4.1.2
4.2
4.3
Основные сведения ........................................................................................................... 168
Расщепление модели ......................................................................................................... 168
Слияние моделей ............................................................................................................... 170
Задание на лабораторную работу..................................................................................... 173
Вопросы для самопроверки .............................................................................................. 174
5 ЛАБОРАТОРНАЯ РАБОТА 5. СОЗДАННОЙ МОДЕЛИ ПРОЦЕССОВ В
ВИДЕ ОРГАНИЗАЦИОННЫХ ДИАГРАММ DFD ....................................... 175
5.1
5.1.1
5.1.2
5.1.3
5.2
5.3
Основные сведения ........................................................................................................... 175
Диаграммы потоков данных (Data Flow Diagramming) ................................................ 175
Стрелки и объекты диаграммы DFD ............................................................................... 175
Построение диаграмм DFD. ............................................................................................. 177
Задание на лабораторную работу..................................................................................... 177
Вопросы для самопроверки .............................................................................................. 179
6 ЛАБОРАТОРНАЯ РАБОТА 6. СОЗДАННОЙ МОДЕЛИ
ИНФОРМАЦИОННЫХ ПОТОКОВ В ВИДЕ ДИАГРАММ WORKFLOW
(IDEF3) ................................................................................................................ 180
6.1
6.1.1
6.1.2
6.1.3
6.1.4
6.1.5
6.2
6.3
Основные сведения ........................................................................................................... 180
Метод описания процессов IDEF3 .................................................................................. 180
Диаграммы IDEF3 ............................................................................................................. 180
Перекрестки (Junction) ...................................................................................................... 183
Объект ссылки ................................................................................................................... 187
Описание сценария, области и точки зрения .................................................................. 190
Задание на лабораторную работу..................................................................................... 191
Вопросы для самопроверки .............................................................................................. 193
7 ЛАБОРАТОРНАЯ РАБОТА 7. СОЗДАННОЕ ОРГАНИЗАЦИОННЫХ
ДИАГРАММ И ДИАГРАММ SWIM LANE ..................................................... 194
7.1
7.1.1
7.1.2
7.2
7.3
Основные сведения ........................................................................................................... 194
Организационные диаграммы .......................................................................................... 194
Диаграммы Swim Lane ....................................................................................................... 199
Задание на лабораторную работу..................................................................................... 201
Вопросы для самопроверки .............................................................................................. 201
8 ЛАБОРАТОРНАЯ РАБОТА 8. СТОИМОСТНОЙ АНАЛИЗ (ACTIVITY
BASED COSTING)............................................................................................... 202
8.1
8.1.1
8.1.2
8.2
8.3
Основные сведения ........................................................................................................... 202
Стоимостный анализ (ABC) .............................................................................................. 202
Свойства, определяемые пользователем (UDP) ............................................................. 208
Задание на лабораторную работу..................................................................................... 213
Вопросы для самопроверки .............................................................................................. 217
9 ЛАБОРАТОРНАЯ РАБОТА 14. СОЗДАНИЕ МОДЕЛИ TO-BE
(РЕИНЖИНИРИНГ БИЗНЕС-ПРОЦЕССОВ) ................................................ 218
Реинжиниринг бизнес-процессов..................................................................................... 218
Задание на лабораторную работу..................................................................................... 218
Расщепление и модификация модели .............................................................................. 218
Слияние модели ................................................................................................................. 220
Использование Model Explorer для реорганизации дерева декомпозиции ................ 221
Модификация диаграммы IDEF3 «Сборка продукта» с целью отображения новой
информации........................................................................................................................ 223
9.2.5 Декомпозиция работы «Продажи и маркетинг»........................................................... 223
9.3
Вопросы для самопроверки .............................................................................................. 224
9.1
9.2
9.2.1
9.2.2
9.2.3
9.2.4
БИБЛИОГРАФИЧЕСКИЙ СПИСОК ................................................................... 225
ВВЕДЕНИЕ
Информационный менеджмент автоматизированных информационных систем
предполагает создание эффективной системы управления на всех этапах жизненного
цикла системы. В жизненном цикле экономической информационной системы (ЭИС)
важным этапом является разработка требований к системе. Требования, предъявляемые к
информационной системе, во много определяются бизнес-процессами предметной
области. При проектировании ЭИС важно не только описать модель существующих на
предприятии бизнес-процессов, но и провести их реинжиниринг. Решение данных задач
невозможно без применения CASE-технологий. Использование CASE-средств при
проектировании ЭИС позволяет автоматизировать основные этапы создания систем,
документировать этапы проектирования и представить результаты в виде удобном для
обсуждения всеми лицами, заинтересованными в проекте: заказчиками, конечными
пользователями и разработчиками.
Широкое распространение в практике создания информационных систем получила
методология структурного анализа SADT (Structured Analysis and Design Technigue) и
принятый на её основе стандарт IDEF0. Инструментальное CASE-средство BPwin 4.0
полностью поддерживает стандарт IDEF0 и предназначено для моделирования бизнеспроцессов.
В предлагаемом лабораторном практикуме рассматриваются основные этапы
создания моделей бизнес-процессов и их реинжиниринга с использованием
инструментального CASE-средства BPwin 4.0.
Лабораторный практикум предназначен для студентов, обучающихся
по специальности 080801 «Прикладная информатика (по областям)», а также
может быть рекомендована для студентов специальности 080507
«Менеджмент» и аспирантов соответствующих специальностей.
Представленный в лабораторном практикуме материал может быть
использован при изучении дисциплин, связанных с разработкой
экономических информационных систем, в процессах курсового и
дипломного проектирования, а также при выполнении научноисследовательских работ аспирантами.
Лабораторная работа. 1
Инструментальные средства BPwin 4.0
Цель работы: Изучить основные функции интегрированной среды разработки
модели бизнес-процессов BPwin 4.0, основные объекты модели бизнес-процессов (работы,
стрелки) и научиться строить контекстную диаграмму бизнес-процесса.
Общие сведения
Общее описание интерфейса BPwin 4.0
BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя,
дающий возможность аналитику создавать сложные модели при минимальных усилиях.
При запуске BPwin по умолчанию появляется основная панель инструментов,
палитра инструментов (вид которой зависит от выбранной нотации) и, в левой части,
навигатор модели -Model Explorer (рис. 1.1).
Рис. 1.1. Интегрированная среда разработки модели BPwin 4.0
Функциональность панели инструментов доступна из основного меню BPwin
(табл.1.1).
Таблица 1.1. Описание элементов управления основной панели инструментов
BPwin 4.0
Элемент
управления
Описание
Соответствующий
пункт меню
Создать новую модель
File/New
Открыть модель
File/Open
Сохранить модель
File/Save
Напечатать модель
File/Print
Вызвать генератор отчетов
Tools/Report Builder
Выбор масштаба
View/Zoom
Масштабирование
View/Zoom
Проверка правописания
Tools/Spelling
Включение и выключение навигатора модели
Model Explorer
View/Model Explorer
Включение и выключение дополнительной панели
ModelMart
инструментов работы с ModelMart
Создание новой модели
При создании новой модели возникает диалог, в котором следует указать, будет ли
создана модель заново, или она будет открыта из файла либо из репозитория ModelMart,
внести имя модели и выбрать методологию, в которой будет построена модель (рис. 1.2).
Как было указано выше, BPwin поддерживает три методологии – IDEF0, IDEF3 и
DFD, каждая из которых решает свои специфические задачи. В BPwin возможно
построение смешанных моделей, т. е. модель может содержать одновременно как
диаграммы IDEF0, так и диаграммы IDEF3 и DFD. Состав палитры инструментов
изменяется автоматически, когда происходит переключение с одной нотации на другую,
поэтому палитра инструментов будет рассмотрена позже.
Рис. 1.2. Диалог создания модели
После щелчка по кнопке ОК появляется диалог Properties for New Models (рис. 1.3),
в котором следует внести свойства модели.
Рис. 1.3. Пример контекстной диаграммы
Модель в BPwin рассматривается как совокупность работ, каждая из которых
оперирует некоторым набором данных. Работа изображается в виде прямоугольников,
данные − в виде стрелок.
Работы (Activity)
Работы обозначают поименованные процессы, функции или задачи, которые
происходят в течение определенного времени и имеют распознаваемые результаты.
Работы изображаются в виде прямоугольников. Все работы должны быть названы и
определены. Имя работы должно быть выражено отглагольным существительным,
обозначающим действие (например, «Изготовление детали», «Прием заказа» и т. д.).
Работа «Изготовление детали» может иметь, например, следующее определение: «Работа
относится к полному циклу изготовления изделия от контроля качества сырья до отгрузки
готового упакованного изделия». При создании новой модели (меню File/New)
автоматически создается контекстная диаграмма с единственной работой, изображающей
систему в целом (рис. 1.3).
Для внесения имени работы следует щелкнуть по работе правой кнопкой мыши,
выбрать в меню Name и в появившемся диалоге внести имя работы. Для описания других
свойств работы служит диалог Activity Properties (рис. 1.4).
Рис. 1.4. Редактор задания свойств работы
Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется
всплывающее контекстное меню, каждый пункт которого соответствует редактору какоголибо свойства объекта модели. При выбора пункта меню на экран выводится редактор
свойств модели (рис. 1.5)
Рис. 1.5. Диалог Properties for New Models
Стрелки (Arrow)
Взаимодействие работ с внешним миром и между собой описывается в виде
стрелок. Стрелки представляют собой некую информацию и именуются
существительными (например, «Сырье», «Чертеж, «Готовое изделие»).
В IDEF0 различают пять типов стрелок:
Вход (Input) − материал или информация, которые используются или
преобразуются работой для получения результата (выхода). Допускается, что работа
может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной
стороне прямоугольника, изображающего работу, или выходит из нее. Стрелка входа
рисуется как входящая в левую грань работы. При описании технологических процессе
(для этого и был придуман IDEF0) не возникает проблем определения входов.
Действительно, «Сырье» на рис. 1.3 − это нечто, что перерабатывается в процессе
«Изготовление изделия». Для получения результата при моделировании информационных
систем, когда стрелками являются не физические объекты, а данные, не все так очевидно.
Например, при «Приеме пациента» карта пациента может быть и на входе и на выход
между тем качество этих данных меняется. Другими словами, в наше примере для того,
чтобы оправдать свое назначение, стрелки входа и выхода должны быть точно
определены с тем, чтобы указать на то, что данные действительно были отображают
(например, на выходе «Заполненная карта пациента»). Очень часто сложно определить
являются ли данные входом или управлением. В этом случае подсказке может служить
следующее: перерабатываются/изменяются ли данные в работе или нет. Если изменяются,
то скорее всего это вход, если нет управление.
Управление (Control) − правила, стратегии, процедуры и стандарты, которыми
руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления.
Стрелка управления рисуете как входящая в верхнюю грань работы. На рис. 1.3 стрелки
«Задание» и «Чертеж» − управление для работы «Изготовление изделия». Управление
влияет на работу, но не преобразуется работой. Если цель работ изменить процедуру или
стратегию, то такая процедура или стратеги будет для работы входом. В случае
возникновения неопределенности статусе стрелки (управление или контроль)
рекомендуется рисовать стрелку управления.
Выход (Output) − материал или информация, которые производятся работой.
Каждая работа должна иметь хотя бы одну стрелку выход. Работа без результата не имеет
смысла и не должна моделироваться Стрелка выхода рисуется как исходящая из правой
грани работы на рис. 1.3 стрелка «Готовое изделие» является выходом для работы
«Изготовление изделия».
Механизм (Mechanism) − ресурсы, которые выполняют работу, например персонал
предприятия, станки, устройства и т.д. Стрелка механизма рисуется как входящая в
нижнюю грань работы. На рис. 1.3 стрелка «Персонал предприятия» является механизмом
для работы «Изготовление изделия». По усмотрению аналитика стрелки механизма могут
не изображаться в модели.
Вызов (Call) - специальная стрелка, указывающая на другую модель работы.
Стрелка механизма рисуется как исходящая из нижней грани работы. На рис. 1.3 стрелка
«Другая модель работы» является вызовом для работы «Изготовление изделия». Стрелка
вызова используется для указания того, что некоторая работа выполняется за пределами
моделируемой системы. В BPwin стрелки вызова используются в механизме слияния и
разделения моделей.
Граничные стрелки. Стрелки на контекстной диаграмме служат для описания
взаимодействия системы с окружающим миром. Они могут начинаться у границы
диаграммы и заканчиваться у работы, и наоборот. Такие стрелки называются граничными.
Для внесения граничной стрелки входа надо:
нннн)
щелкнуть по кнопке с символом стрелки
в палитре
инструментов и перенести курсор к левой стороне экрана, пока не
появится начальная темная полоска;
оооо) щелкнуть один раз по полоске (откуда выходит стрелка) и еще
раз в левой части работы со стороны входа (где заканчивается
стрелка);
пппп)
вернуться в палитру инструментов и выбрать опцию
редактирования стрелки ;
рррр) щелкнуть правой кнопкой мыши на линии стрелки, во
всплывающем меню выбрать Name и добавить имя стрелки во
вкладке Name диалога Arrow Properties (рис. 1.6).
Рис. 1.6. Диалог Arrow Properties
Стрелки управления, выхода и механизма вводятся в модель аналогично. Для
рисования стрелки выхода, например, следует щелкнуть по кнопке с символом стрелки в
палитре инструментов, щелкнуть в правой части работы со стороны выхода (где
начинается стрелка), перенести курсор к правой стороне экрана, пока не появится
начальная штриховая полоска, и щелкнуть один раз по штриховой полоске.
Установка цвета и шрифта объектов
Пункты контекстного меню Font и Color вызывают диалог Arrow Properties или
Activity Properties для установки шрифта (в том числе его размера и стиля) и цвета
объекта. В нижней части вкладки Font диалогов Arrow Properties и Activity Properties (рис.
1.7) находятся группа опций Apply setting to, позволяющих изменить шрифт для всех работ
или стрелок на текущей диаграмме, в модели, и группа Global, позволяющая изменить
шрифт одновременно для всех объектов модели.
Кроме того, BPwin позволяет установить шрифт по умолчанию для объектов
определенного типа на диаграммах и в отчетах. Для этого следует выбрать меню
Model/Default Fonts, после чего появляется каскадное меню, каждый пункт которого
служит для установки шрифтов для определенного типа объектов:
сссс) Context Activity - работа на контекстной диаграмме;
тттт) Context Arrow - стрелки на контекстной диаграмме;
уууу) Decomposition Activity - работы на диаграмме декомпозиции;
фффф)
Decomposition Arrow - стрелки на диаграмме декомпозиции;
Рис. 1.7. Вкладка Font диалога Activity Properties
хххх) Node Tree Text - текст на диаграмме дерева узлов;
цццц)
Frame User Text - текст, вносимый пользователем в каркасе
диаграмм:
чччч) Frame System Text — системный текст в каркасе диаграмм;
шшшш)
Text Blocks - текстовые блоки;
щщщщ)
Parent Diagram Text - текст родительской диаграммы;
ыыыы)
Parent Diagram Title Text - текст заголовка родительской
диаграммы;
ээээ) Report Text - текст отчетов.
Model Explorer - навигатор модели
Инструмент навигации Model Explorer имеет три вкладки - Activities, Diagrams и
Objects. Вкладка Activities (рис. 1.7) показывает в виде раскрывающегося иерархического
списка все работы модели. Одновременно могут быть показаны все модели, открытые в
BPwin. Работы с диаграмм IDEF0 показываются зеленым цветом, IDEF3 - желтым и DFD
- голубым.
Щелчок по работе во вкладке Activity переключает левое окно BPwin на диаграмму,
на которой эта работа размещена. Для редактирования свойств работы следует щелкнуть
по ней правой кнопкой мыши. Появляется контекстное меню. В табл. 1.2 приведено
значение пунктов меню.
Если с помощью вкладки Activities можно перейти на стандартные диаграммы, то
вторая вкладка -Diagrams (рис. 1.5) - служит для перехода на любую диаграмму модели.
Рис. 1.7. Вкладка Activities навигатора Model Explorer
После перехода на вкладку Objects на ней показываются все объекты,
соответствующие выбранной на вкладке Diagrams диаграмме, в том числе работы,
хранилища данных, внешние ссылки, объекты ссылок и перекрестки.
Таблица 1.2. Контекстное меню редактирования свойств работы
Пункт меню
Описание
Insert Before
Создать новую работу на той же самой диаграмме. В списке работ
новая работа будет вставлена перед текущей
Insert After
Создать новую работу на той же самой диаграмме. В списке работ
новая работа будет вставлена после текущей.
Decompose
Декомпозировать работу. В результате будет создана новая диаграмма
декомпозиции
Name
Вызов редактора имени работы
Definition/Note
Вызов редактора определения и примечания к работе
Font
Изменения шрифта работы
Color
Изменения цвета работы
Costs
Задание стоимости работе
Data Usage
Ассоциация работы с данными
UDP
Задание свойств, определяемых пользователем
UOW
Задание свойств для работ IDEF3
Задание на выполнение лабораторной работы
Для моделирования бизнес-процессов рассмотрим деятельность компании,
которая занимается, в основном, сборкой и продажей настольных компьютеров и
ноутбуков. Компания не производит компоненты самостоятельно, а только собирает и
тестирует компьютеры.
Основные процедуры в компании таковы:
юююю)
продавцы принимают заказы клиентов;
яяяя) операторы группируют заказы по типам компьютеров;
ааааа)
операторы собирают и тестируют компьютеры;
ббббб)
операторы упаковывают компьютеры согласно заказам;
ввввв)
кладовщик отгружает клиентам заказы.
Компания использует купленную бухгалтерскую информационную систему,
которая позволяет оформить заказ, счет и отследить платежи по счетам.
Для построения контекстной диаграммы необходимо выполнить следующие
действия.
1. Запустите BPwin. (Кнопка Start/BPwin).
2. Если появляется диалог ModelMart Connection Manager, нажмите на
кнопку Cancel.
3. Щелкните по кнопке
появляется диалог I would like to. Внесите
имя модели «Деятельность компании» и выберите Туре - IDEF0. Нажмите
ОК.
4. Автоматически создается контекстная диаграмма.
5. Обратите внимание на кнопку
на панели инструментов. Эта
кнопка включает и выключает инструмент просмотра и
навигации - Model Explorer (появляется слева). Model Explorer
имеет три вкладки - Activities, Diagrams и Objects. Во вкладке
Activities щелчок правой кнопкой по объекту позволяет
редактировать его свойства.
6. Если вам непонятно, как выполнить то или иное действие, вы
можете вызвать помощь - клавиша F1 или меню Help.
7. Перейдите в меню Model/Model Properties. Во вкладке General
диалога Model Properties следует внести имя модели
«Деятельность компании», имя проекта «Модель деятельности
компании», имя автора и тип модели - Time Frame: AS-IS.
8. Во вкладке Purpose внесите цель - Purpose: «Моделировать
текущие (AS-IS) бизнес-процессы компании» и точку зрения Viewpoint: «Директор».
9. Во вкладке Definition внесите определение «Это учебная модель,
описывающая деятельность компании» и цель Scope: «Общее
управление бизнесом компании: исследование рынка, закупка
компонентов, сборка, тестирование и продажа продуктов».
10. Перейдите на контекстную диаграмму и правой кнопкой мыши
щелкните по работе. В контекстном меню выберите Name. Во
вкладке Name внесите имя «Деятельность компании».
11. Во вкладке Definition внесите определение «Текущие бизнеспроцессы компании».
12. Создайте стрелки на контекстной диаграмме в соответствии с
пояснениями, приведенными в табл. 1.3.
Вопросы для самопроверки
1.
2.
3.
4.
5.
Что моделируют работы в модели бизнес-процессов?
Как должны именоваться работы модели бизнес-процессов?
Что моделируют стрелки в модели бизнес-процессов?
Какие типы стрелок используются в моделях IDEF0?
Какие имеются ограничения на использование стрелок (направления и
расположение) в моделях IDEF0?
Таблица 1.3. Стрелки контекстной диаграммы
Arrow Name
Arrow Definition
Arrow
Type
Бухгалтерская система
Оформление счетов, оплата счетов, работа с заказами
Mechanism
Звонки клиентов
Запросы информации, заказы, техподдержка и т.д.
Input
Правила и процедуры
Проданные продукты
Правила продаж, инструкции по сборке, процедуры тестирования,
критерии производительности и т. д.
Настольные и портативные компьютеры
13. С помощью кнопки
зрения и цель (рис.1.8).
Control
Output
внесите текст в поле диаграммы - точку
Рис. 1.8. Внесение текста в поле диаграммы с помощью редактора Text Block
Editor
Результат выполнения лабораторной работы 1 показан на рис. 1.9.
Рис. 1.9. Контекстная диаграмма
14. Создайте отчет по модели. Меню Tools/Reports/Model Report.
В окне Model Report определяется информация, которая включается в отчет (рис.
1.10).
Рис. 1.10. Окно Model Report
После нажатия клавиши Preview отчет выводится на экран (рис. 1.11)
Рис. 1.11. Вывод отчета на экран
Лабораторная работа. 2
Создание диаграммы декомпозиции
Цель работы: Изучить методы и объекты декомпозиции модели бизнес-процессов,
научиться строить простейшие диаграммы декомпозиции бизнес-процессов первого
уровня.
Общие сведения
Диаграммы декомпозиции
Диаграммы декомпозиции содержат родственные работы, т.е. дочерние работы,
имеющие общую родительскую работу. Для создания диаграммы декомпозиции следует
выделить курсором определенную работу и щелкнуть по кнопке
(рис. 2.1).
Рис. 2.1. Кнопка перехода на нижний уровень декомпозиции
Возникает диалог Activity Box Count (рис. 2.2), в котором следует указать нотацию
новой диаграммы (например IDEF0) и количество работ на ней.
Рис. 2.2. Диалог Activity Box Count
Следует отметить, что нотации IDEF0 являются нотациями методики
функционального моделирования систем. Допустимый интервал числа работ 2-8.
Декомпозировать работу на одну работу не имеет смысла: диаграммы с количеством
работ более восьми получаются перенасыщенными и плохо читаются. Для обеспечения
наглядности и лучшего понимания моделируемых процессов рекомендуется использовать
от 3 до 6 блоков на одной диаграмме.
Пример декомпозиции контекстной диаграммы из лабораторной работы 1 (см. рис.
1.3) на четыре работы приведен на рис. 2.3.
Если оказывается, что количество работ недостаточно, то работу можно добавить в
диаграмму, щелкнув сначала по кнопке
свободному месту на диаграмме.
на палитре инструментов, а затем по
Рис.2.3. Пример диаграммы декомпозиции
Работы на диаграммах декомпозиции обычно располагаются по диагонали от
левого верхнего угла к правому нижнему.
Такой порядок называется порядком доминирования. Согласно этому принципу
расположения в левом верхнем углу располагается самая важная работа или работа,
выполняемая по времени первой.
Далее вправо вниз располагаются менее важные или выполняемые позже работы.
Такое расположение облегчает чтение диаграмм, кроме того, на нем основывается
понятие взаимосвязей работ.
После задания имен работам и стрелкам, соединения и добавления стрелок
диаграмма декомпозиции примет вид, показанный на рис. 2.4 (диаграмма дается для
иллюстрации примера декомпозиции и последующего объяснения теоретического
материала).
Каждая из работ на диаграмме декомпозиции может быть, в свою очередь
декомпозирована. На диаграмме декомпозиции работы нумеруются автоматически слева
направо. Номер работы показывается в правом нижнем углу. В левом верхнем углу
изображается небольшая диагональная черта, которая показывает, что данная работа не
была декомпозирована.
Имена вновь внесенных стрелок автоматически заносятся в словарь (Arrow
Dictionary). Словарь стрелок редактируется при помощи специального редактора Arrow
Dictionary, в котором определяется стрелка и вносится относящийся к ней комментарий
(рис. 2.5).
Рис. 2.4. Диаграмма декомпозиции
Рис. 2.5. Словарь стрелок
Словарь стрелок решает важную задачу. Диаграммы создаются аналитиком для
того, чтобы провести сеанс экспертизы, т.е. обсудить диаграмму со специалистом
предметной области. В любой предметной области формируется профессиональный
жаргон, причем очень часто жаргонные выражения имеют нечеткий смысл и
воспринимаются разными специалистами по-разному. В то же время аналитик − автор
диаграмм вынужден употреблять выражения, которые наиболее понятны экспертам.
Поскольку формальные определения часто сложны для восприятия, аналитик вынужден
употреблять профессиональный жаргон, а, чтобы не возникло неоднозначных трактовок, в
словаре стрелок каждому понятию можно дать расширенное и, если это необходимо,
формальное определение.
Помимо словаря стрелок BPwin содержит еще 14 словарей (работ, хранилищ
данных, внешних ссылок, объектов ссылок, перекрестков, сущностей, атрибутов, центров
затрат, ресурсов, ролей, групп ролей, свойств UDP, ключевых слов UDP и изображений).
Интерфейс большинства словарей унифицирован. Смысл кнопок панели управления
словаря приведен в табл. 2.1.
Содержимое словаря стрелок можно распечатать в виде отчета (меню
Tools/Reports/Arrow Report) и получить тем самым толковый словарь терминов
предметной области, использующихся в модели.
Таблица 2.1. Кнопки панели управления словаря (слева направо)
Кнопка
Предназначение
Сохранить словарь
Предварительный просмотр печати словаря
Печать словаря
Экспорт словаря в текстовый файл
Импорт словаря из текстового файла
Удаление объектов из словаря. Удалить можно только те объекты, которые не используются в
модели
Диаграмма декомпозиции предназначена для детализации работы. В отличие от
моделей, отображающих структуру организации, работа на диаграмме верхнего уровня в
IDEF0 − это не элемент управления нижестоящими работами. Работы нижнего уровня −
это то же самое, что и работы верхнего уровня, но в более детальном изложении. Как
следствие этого границы работы верхнего уровня - это то же самое, что и границы
диаграммы декомпозиции. ICOM (аббревиатура от Input, Control, Output и Mechanism) −
коды, предназначенные для идентификации граничных стрелок. Код ICOM содержит
префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер (рис. 2.6).
Рис. 2.6. Фрагмент диаграммы декомпозиции с ICOM-кодам (I1, С1 и С2)
BPwin вносит ICOM-коды автоматически. Для отображения ICOM-кодов следует
включить опцию ICOM codes на вкладке Display диалога Model Properties (меню
Model/Model Properties).
Стрелки на диаграммах декомпозиции
Несвязанные граничные стрелки (unconnected border arrow). При декомпозиции
работы входящие в нее и исходящие из нее стрелки (кроме стрелки вызова) автоматически
появляются на диаграмме декомпозиции (миграция стрелок), но при этом не касаются
работ. Такие стрелки называются несвязанными и воспринимаются в BPwin как
синтаксическая ошибка.
На рис. 2.3 приведена диаграмма декомпозиции с несвязанными стрелками,
генерирующийся BPwin при декомпозиции работы "Изготовление изделия".
Для связывания стрелок входа, управления или механизма необходимо перейти в
режим редактирования стрелок, щелкнуть по наконечнику стрелки и щелкнуть по
соответствующему сегменту работы. Для связывания стрелки выхода необходимо перейти
в режим редактирования стрелок, щелкнуть по сегменту выхода работы и затем по
стрелке.
Внутренние стрелки. Для связи работ между собой используются внутренние
стрелки, т.е. стрелки, которые не касаются границы диаграммы, начинаются у одной и
кончаются у другой работы.
Для рисования внутренней стрелки необходимо в режиме рисования стрелок
щелкнуть по сегменту (например, выхода) одной работы и затем по сегменту (например,
входа) другой.
В IDEF0 различают пять типов связей работ.
Связь по входу (output-input), когда стрелка выхода вышестоящей работы (далее просто выход) направляется на вход нижестоящей (например, на рис. 2.7 стрелка
"Детали" связывает работы "Изготовление деталей" и "Сборка изделия").
Рис. 2.7. Связь по входу
Связь по управлению (output-control), когда выход вышестоящей работы
направляется на управление нижестоящей. Связь по входу показывает доминирование
вышестоящей работы. Данные или объекты выхода вышестоящей работы не меняются в
нижестоящей. На рис. 2.8 стрелка «Чертеж» связывает работы «Создание чертежа
детали» и «Изготовление детали», при этом чертеж не претерпевает изменений в
процессе изготовления деталей.
Рис. 2.8. Связь по управлению
Обратная связь по входу (output-input feedback), когда выход нижестоящей
работы направляется на вход вышестоящей. Такая связь, как правило, используется для
описания циклов. На рис. 2.9 стрелка «Ошибка ввода» связывает работы «Проверка
бизнес-правил» и «Ввод данных», при этом выявленные на этапе проверки правильности
ввода ошибки в данных должны направляться на повторный ввод.
Рис. 2.9. Обратная связь по входу
Обратная связь по управлению (output-control
нижестоящей
работы направляется
на
управление
«Рекомендации», рис. 2.10).
feedback), когда выход
вышестоящей
(стрелка
Рис. 2.10. Обратная связь по управлению
Обратная связь по управлению часто свидетельствует об эффективности бизнеспроцесса. В случае, изображенном на рис. 2.9, качество изделия может быть повышено
путем непосредственного регулирования процессами изготовления деталей и сборки
изделия в зависимости от результата (выхода) работы «Контроль качества».
Связь выход-механизм (output-mechanism), когда выход одной работы
направляется на механизм другой. Эта взаимосвязь используется реже остальных и
показывает, что одна работа подготавливает ресурсы, необходимые для проведения
другой работы (рис. 2.11).
Рис. 2.11. Связь выход-механизм
Явные стрелки. Явная стрелка имеет источником одну-единственную работу и
назначением тоже одну-единственную работу.
Разветвляющиеся и сливающиеся стрелки. Одни и те же данные или объекты,
порожденные одной работой, могут использоваться сразу в нескольких других работах. С
другой стороны, стрелки, порожденные в разных работах, могут представлять собой
одинаковые или однородные данные или объекты, которые в дальнейшем используются
или перерабатываются в одном месте. Для моделирования таких ситуаций в IDEF0
используются разветвляющиеся и сливающиеся стрелки. Для разветвления стрелки нужно
в режиме редактирования стрелки щелкнуть по фрагменту стрелки и по
соответствующему сегменту работы. Для слияния двух стрелок выхода нужно в режиме
редактирования стрелки сначала щелкнуть по сегменту выхода работы, а затем по
соответствующему фрагменту стрелки.
Смысл разветвляющихся и сливающихся стрелок передается именованием каждой
ветви стрелок. Существуют определенные правила именования таких стрелок.
Рассмотрим их на примере разветвляющихся стрелок.
Если стрелка именована до разветвления, а после разветвления ни одна из ветвей
не именована, то подразумевается, что каждая ветвь моделирует те же данные или
объекты, что и ветвь до разветвления (рис. 2.12).
Если стрелка именована до разветвления, а после разветвления какая-либо из
ветвей не именована, то подразумевается, что эти ветви соответствуют именованию. Если
при этом какая-либо ветвь после разветвления осталась неименованной, то
подразумевается, что она моделирует те же данные или объекты, что и ветвь до
разветвления (рис. 2.13).
Рис. 2.12. Пример именования разветвляющейся стрелки
Рис. 2.13. Другой пример именования разветвляющейся стрелки
Недопустима ситуация, когда стрелка до разветвления не именована, а после
разветвления не именована какая-либо из ветвей. BPwin определяет такую стрелку как
синтаксическую ошибку (рис. 2.114).
Рис. 2.14. Пример неверного именования разветвляющейся стрелки
Правила именования сливающихся стрелок полностью аналогичны − ошибкой
будет считаться стрелка, которая после слияния не именована, а до слияния не именована
какая-либо из ее ветвей. Для именования отдельной ветви разветвляющихся и
сливающихся стрелок следует выделить на диаграмме только одну ветвь, после этого
вызвать редактор имени и присвоить имя стрелке. Это имя будет соответствовать только
выделенной ветви.
Тоннелирование стрелок. Вновь внесенные граничные стрелки на диаграмме
декомпозиции нижнего уровня изображаются в квадратных скобках и автоматически не
появляются на диаграмме верхнего уровня (рис. 2.15).
Рис. 2.15. Неразрешенная (unresolved) стрелка
Для их «перетаскивания» наверх нужно щелкнуть по квадратным скобкам
граничной стрелки правой кнопкой мыши и в контекстном меню выбрать пункт «Arrow
Tunnel». Появляется диалог Border Arrow Editor (рис. 2.16).
Рис. 2.16. Диалог Border Arrow Editor
Если выбрать опцию Resolve it to border arrow, стрелка мигрирует на диаграмму
верхнего уровня, а если Change it to resolved rounded tunnel -стрелка будет
затоннелирована и не попадет на другую диаграмму. Тоннельная стрелка изображается с
круглыми скобками на конце (рис. 2.17).
Рис. 2.17. Типы тоннелирования стрелок
Тоннелирование может быть применено для изображения малозначимых стрелок.
Если на какой-либо диаграмме нижнего уровня необходимо изобразить малозначимые
данные или объекты, которые не обрабатываются или не используются работами на
текущем уровне, то их необходимо направить на вышестоящий уровень (на родительскую
диаграмму). Если эти данные не используются на родительской диаграмме, их нужно
направить еще выше и т.д. В результате малозначимая стрелка будет изображена на всех
уровнях и затруднит чтение всех диаграмм, на которых она присутствует. Выходом
является тоннелирование стрелки на самом нижнем уровне. Такое тоннелирование
называется «не-в-родительской-диаграмме».
Другим примером тоннелирования может быть ситуация, когда стрелка механизма
мигрирует с верхнего уровня на нижний, причем на нижнем уровне этот механизм
используется одинаково во всех работах без исключения. (Предполагается, что не нужно
детализировать стрелку механизма, т. е. стрелка механизма на дочерней работе именована
до разветвления, а после разветвления ветви не имеет собственного имени.) В этом случае
стрелка механизма на нижнем уровне может быть удалена, после чего на родительской
диаграмме она может быть затоннелирована, а в комментарии к стрелке или в словаре
можно указать, что механизм будет использоваться во всех работах дочерней диаграммы
декомпозиции. Такое тоннелирование называется «не-в-дочерней-работе» (рис. 2.17).
Задание на лабораторную работу
В процессе выполнения лабораторной работы необходимо построить диаграмму
декомпозиции контекстной диаграммы, разработанной в первой лабораторной работе
(рис. 1.9).
1. В результате анализа бизнес-процессов предприятия было решено на первом
уровне декомпозиции выделить следующие бизнес-процессы:
ггггг) продажа и маркетинг;
ддддд)
сборка и тестирование компьютеров;
еееее)
отгрузка заказов клиентам и получение компонентов от
поставщиков.
Постройте диаграмму декомпозиции, включив в неё три вышеперечисленные
работы.
2. На диаграмме декомпозиции задайте имена и определения для работ в
соответствии с табл. 2.2.
Таблица 2.2. Работы диаграммы декомпозиции А0
Activity Name
Продажи и маркетинг
Сборка
и
тестирование
компьютеров
Отгрузка и получение
Definition
Телемаркетинг и презентации, выставки
Сборка и тестирование настольных и портативных компьютеров
Отгрузка заказов клиентам и получение компонентов от поставщиков
3. Свяжите граничные стрелки как показано на рис. 2.18
Рис. 2.18. Связанные граничные стрелки на диаграмме А0
4. Для уточнения назначения стрелки «Правила и процедуры» для управления
работой «Сборка и тестирование компьютеров» переименуйте её в «Правила сборки и
тестирования» (рис. 2.19). Внесите определение для новой ветви: «Инструкции по
сборке, процедуры тестирования, критерии производительности и т.д.»
5. Соедините работы 1 и 2 стрелкой «Заказы клиентов», а работы 2 и 3 –
«Собранные компьютеры»
Рис. 2.19. Уточнение назначения механизма управления – формирование
стрелки «Правила сборки и тестирования»
6. Создайте стрелку обратной связи (по управлению) «Результаты сборки и
тестирования», идущую от выхода работы «Сборка и тестирование компьютеров» к
управлению работы «Продажи и маркетинг». Измените стиль стрелки обратной
связи (толщина линий) и установите опцию Extra Arrowhead (из контекстного
меню). Методом drag&drop перенесите имена стрелок так, чтобы их было удобнее
читать. Если необходимо, установите опцию Squiggle (из контекстного меню),
которая формирует указатель связи имени стрелки и самой стрелки
7. Создайте новую граничную стрелку выхода «Маркетинговые материалы»,
выходящую из работы «Продажи и маркетинг». Результат выполнения показан на рис.
2.20.
Рис. 2.20. Результат выполнения упражнения 2 − диаграмма А0
8. Декомпозируйте работу «Сборка и тестирование компьютеров» на 4 работы.
В результате проведения экспертизы получена следующая информация.
Производственный отдел получает заказы клиентов от отдела продаж по мере их
поступления. Диспетчер координирует работу сборщиков, сортирует заказы, группирует
их и дает указание на отгрузку компьютеров, когда они готовы. Каждые 2 часа диспетчер
группирует заказы − отдельно для настольных компьютеров и ноутбуков и направляет на
участок сборки. Сотрудники участка сборки собирают компьютеры согласно
спецификациям заказа и инструкциям по сборке. Когда группа компьютеров,
соответствующая группе заказов, собрана, она направляется на тестирование.
Тестировщики тестируют каждый компьютер и в случае необходимости заменяют
неисправные компоненты. Тестировщики направляют результаты тестирования
диспетчеру, который на основании этой информации принимает решение о передаче
компьютеров, соответствующих группе заказов, на отгрузку.
На основе приведенной выше информации внесите новые работы (табл. 2.3) и
стрелки диаграммы декомпозиции А2 (табл. 2.4).
Таблица 2.3. Работы диаграммы декомпозиции А2
Activity Name
Отслеживание
расписания
управление сборкой и тестированием
Activity Definition
и
Просмотр заказов, установка расписания выполнения заказов, просмотр
результатов тестирования, формирование групп заказов на сборку и отгрузку
Сборка настольных компьютеров
Сборка настольных компьютеров
инструкциями и указаниями диспетчера
в
соответствии
с
Сборка ноутбуков
Сборка ноутбуков в соответствии с инструкциями и указаниями
диспетчера
Тестирование компьютеров
Тестирование компьютеров и компонентов. Замена неработающих
компонентов
Таблица 2.4. Стрелки диаграммы декомпозиции А2
Arrow
Name
Arrow Source
Arrow
Source
Type
Arrow Dest.
2
3
4
1
Персонал
производственного отдела
Диспетчер
Заказы
клиентов
Граница диаграммы
Заказы
настольные
компьютеры
Заказы
ноутбуки
на
на
Отслеживание расписания
и управление сборкой и
тестированием
Отслеживание расписания
и управление сборкой и
тестированием
Control
Output
Output
Настольные
компьютеры
Ноутбуки
«Tunnel»
Сборка
компьютеров
Input
настольных
Сборка ноутбуков
Mechanism
Отслеживание расписания и
управление
сборкой
и
тестированием
Control
Сборка
компьютеров
Control
Сборка ноутбуков
настольных
Сборка ноутбуков
Control
Input
Input
Input
Output
Тестирование
компьютеров
Input
Output
Тестирование
компьютеров
Input
Сборка
«Tunnel»
настольных
Тестирование
компьютеров
Персонал
производственного
5
Отслеживание расписания и
управление
сборкой
и
тестированием
Сборка
компьютеров
Компоненты
Arrow
Dest. Type
Mechanism
настольных
Mechanism
компьютеров
отдела
Сборка ноутбуков
Mechanism
Продолжение табл. 2.4
1
3
2
5
4
Сборка
настольных
компьютеров
Правила сборки и
тестирования
Граница диаграммы
Сборка
настольных
компьютеров
Сборка ноутбуков
Control
Тестирование компьютеров
Control
Граница диаграммы
Output
Output
Результаты сборки
и тестирования
Control
Сборка ноутбуков
Output
Тестирование компьютеров
Output
Отслеживание расписания и
Результаты
Тестирование компьютеров
тестирования
Output
управление
сборкой
и
Input
тестированием
Собранные
Тестирование компьютеров
компьютеры
Тестировщик
Output
Персонал производственного
Граница диаграммы
Output
Тестирование компьютеров
Mechanism
Тестирование компьютеров
Control
отдела
Указание передать
компьютеры
отгрузку
Отслеживание расписания и
на управление
сборкой
Output
и
тестированием
9. Туннелируйте и свяжите на верхнем уровне граничные стрелки, если это
необходимо.
Результат декомпозиции работы «Сборка и тестирование компьютеров» показан
на рис. 2.21.
Рисунок 2.21. Результат декомпозиции работы «Сборка и тестирование
компьютеров»
10. Декомпозируйте работу «Продажа и маркетинг» на три работы:
жжжжж) «Предоставление информации о ценах»;
ззззз) «Оформление заказов»;
иииии)
«Исследование рынка».
Результаты декомпозиции работы «Продажа и маркетинг» приведены на рис.
2.22.
Рисунок 2.21. Результат декомпозиции работы Продажа и маркетинг»
Сохраните модель для следующих лабораторных работ.
Вопросы для самопроверки
1. Для чего проводят декомпозицию работ модели бизнес-процессов?
2. Какие существуют рекомендации по допустимому интервалу числа работ в
модели декомпозиции?
3. Почему работы на диаграммах декомпозиции обычно располагаются по
диагонали от левого верхнего угла к правому нижнему?
4. Что означает небольшая диагональная черта в левом верхнем углу работы?
5. Для чего используют коды ICOM?
6. Что означает понятие «миграция стрелок»?
7. Когда появляются на диаграммах несвязанные граничные стрелки?
8. Для чего используются внутренние стрелки?
9. Что такое «связь по входу»?
10. Что такое «связь по управлению»?
11. Что такое «обратная связь по входу»?
12. Что такое «обратная связь по управлению»?
13. Что такое «выход - механизм»?
14. Поясните как правильно именовать разветвляющиеся стрелки?
15. Для чего используется тоннелирование стрелок?
16. Как должен изображаться туннель «не в родительской диаграмме»?
17. Как должен изображаться туннель «не в дочерней диаграмме»?
Лабораторная работа 3.
Создание диаграммы узлов
Цель работы: Изучить методы построения функциональных диаграмм в виде
дерева узлов.
Основные сведения
Диаграммы дерева узлов
Представление информационной системы в виде функциональной схемы является
распространенным способом моделирования функциональности системы. Диаграмма
дерева узлов показывает иерархию работ в модели и позволяет рассмотреть всю модель
целиком, но не показывает взаимосвязи между работами (стрелки) (рис. 3.1).
Рисунок 3.1. Диаграмма дерева узлов
Процесс создания модели работ является итеративным, следовательно, работы
могут менять свое расположение в дереве узлов многократно. Чтобы не запутаться и
проверить способ декомпозиции, следует после каждого изменения создавать диаграмму
дерева узлов. Впрочем, BPwin имеет мощный инструмент навигации по модели – Model
Explorer, который позволяет представить иерархию работ и диаграмм в удобном и
компактном виде, однако этот инструмент не является составляющей стандарта IDEF0.
Для создания диаграммы дерева узлов следует выбрать в меню пункт Diagram/Add
Node Tree. В результате на экране появится форма эксперт создания диаграммы дерева
узлов «Node Tree Wizard» (рис. 3.2).
На первом шаге диалога эксперта необходимо внести имя диаграммы дерева узлов,
узел верхнего уровня и глубину дерева − Number of Levels (по умолчанию 3). Это
необходимо поскольку дерево узлов не обязательно должно иметь в качестве верхнего
уровня контекстную работу и произвольную глубину.
Рисунок 3.2. Эксперт создания диаграммы дерева узлов. Шаг 1.
В одной модели можно создавать множество диаграмм деревьев узлов. Имя дерева
узлов по умолчанию совпадает с именем работы верхнего уровня, а номер диаграммы
автоматически генерируется как номер узла верхнего уровня плюс литера «N», например
A0N. Если в модели создается два дерева узлов, имеющих в качестве верхнего уровня
одну и ту же работу, то по умолчанию диаграммы получат идентичные номер и имя.
Поэтому рекомендуется при создании диаграммы дерева узлов внести имя диаграммы,
отличное от значения по умолчанию. Второй шаг диалога эксперта Node Tree Wizard
(рисунок 3.3) позволяет задать свойства диаграммы дерева узлов.
Рис. 3.3. Эксперт создания диаграммы дерева узлов. Шаг 2.
По умолчанию нижний уровень декомпозиции показывается в виде списка,
остальные работы – в виде прямоугольников (рис. 3.4). Для отображения всего дерева в
виде прямоугольников следует выбрать опцию Bullet Last Level. Группа Connection Style
позволяет выбрать стиль соединительных линий – диагональные (по умолчанию) или
ортогональные.
Рис. 3.4. Отображения всего дерева в виде прямоугольников.
Диаграммы FEO
Диаграммы «только для экспозиции» (FEO) часто используются в модели для
иллюстрации других точек зрения, для отображения отдельных деталей, которые не
поддерживаются явно синтаксисом IDEF0. Диаграммы FEO позволяют нарушить любое
синтаксическое правило, поскольку, по сути, являются просто картинками – копиями
стандартных диаграмм и не включаются в анализ синтаксиса. Например, работа на
диаграмме FEO может не иметь стрелок управления и выхода. С целью обсуждения
определенных аспектов модели с экспертом предметной области может быть создана
диаграмма только с одной работой и одной стрелкой, поскольку стандартная диаграмма
декомпозиции содержит множество деталей, не относящихся к теме обсуждения и
дезориентирующих эксперта. Для создания диаграммы FEO следует выбрать пункт меню
Diagram/Add FEO Diagram. В возникающем диалоге Add New FEO Diagram следует
указать имя диаграммы FEO и тип родительской диаграммы (рис. 3.5).
Рисунок 3.5. Эксперт создания диаграммы FEO
Новая диаграмма (рис. 3.6) получает номер, который генерируется автоматически
(номер родительской диаграммы по узлу + постфикс F, например A0F).
Рис. 3.6. Отображения диаграммы FEO
Задание на лабораторную работу
1. Для модели, созданной при выполнении лабораторной работы 2, постройте
диаграмму дерева узлов с изображением нижних уровней декомпозиции в виде списка и в
виде прямоугольников.
2. Для детального обсуждения бизнес-процессов работы «Сборка и
тестирование компьютеров» создайте FEO-диаграмму, на которой будут только
стрелки работы «Сборка и тестирование компьютеров». Удалите лишние стрелки на
диаграмме FEO. Результат должен соответствовать рис. 3.7.
Рис. 3.7. Диаграмм FEO «Сборка и тестирование компьютеров»
Для перехода между стандартной диаграммой, деревом узлов и FEO используется
кнопка на палитре инструментов.
Вопросы для самопроверки
1. Как представляются функциональные схемы инструментарием BPwin?
2. Можно ли с помощью BPwin 4.0 создавать многоуровневые функциональные
схемы?
3. Для чего используются диаграммы FEO?
4. Почему диаграммы FEO являются более удобными при рассмотрении модели с
различных точек зрения?
Лабораторная работа 4.
Расщепление и слияние моделей
Цель работы: Изучить методы слияния и расщепления моделей, которые
необходимы для обеспечения коллективной работы над проектом.
Основные сведения
Возможность слияния и расщепления моделей необходима для обеспечения
коллективной работы над проектом. Так, руководитель проекта может создать
декомпозицию верхнего уровня и дать задание аналитикам продолжить декомпозицию
каждой ветви дерева в виде отдельных моделей. После окончания работы над отдельными
ветвями все подмодели могут быть слиты в единую модель. С другой стороны, отдельная
ветвь модели может быть отщеплена для использования в качестве независимой модели,
для доработки или архивирования.
Для слияния и разветвления моделей в BPwin используются стрелки вызова.
Расщепление модели
Для отщепления ветви от модели следует щелкнуть правой кнопкой мыши по
декомпозированной работе, например «Изготовление деталей» (работа не должна иметь
диагональной черты в левом верхнем углу) и выбрать во всплывающем меню пункт Split
Model (рис. 4.1). В появившемся диалоге Split Options следует указать имя создаваемой
модели, например «Изготовление деталей». После подтверждения расщепления в старой
модели работа станет недекомпозированной (признак - диагональная черта в левом
верхнем углу), будет создана стрелка вызова (рис. 4.2), причем ее имя будет совпадать с
именем новой модели, и, наконец, будет создана новая модель, причем имя контекстной
работы будет совпадать с именем работы, от которой была «оторвана» декомпозиция, т.е.
«Изготовление деталей» (рис. 4.3).
Рис. 4.1. Выбор режима расщепления модели
Рис. 4.2. Модель с отщепленной работой «Изготовление деталей»
Рис. 4.3. Представление новой модели «Изготовление деталей» в браузере
Слияние моделей
Что бы произвести слияние моделей необходимо выполнить следующие условия:
ккккк)
обе сливаемые модели должны быть открыты в BPwin;
ллллл)
имя модели-источника, которое присоединяют к моделицели, должно совпадать с именем стрелки вызова работы в моделицели (рис. 4.4);
Модель работы
Цель
Работа
Имена работ
должны совпадать
Источник
Модель работы1
Модель
работы 1
Работа
Рис. 4.4. Условия слияния моделей
ммммм) стрелка вызова должна исходить из недекомпозируемой
работы (работа должна иметь диагональную черту в левом верхнем
углу) (рис. 4.5);
ннннн)
имена контекстной работы подсоединяемой моделиисточника и работы на модели-цели, к которой мы подсоединяем
модель-источник, должны совпадать (рис. 4.4);
ооооо)
модель-источник должна иметь, по крайней мере, одну
диаграмму декомпозиции.
Собранные
изделия
Детали
Сборка изделия
Модель
сборки
Рис. 4.5. Стрелка вызова работы «Сборка изделия» модели − цели
Для слияния моделей необходимо выделить работу, с которой будет сливаться
модель и правой кнопкой мыши вызвать контекстное меню. В контекстном меню выбрать
пункт Merge Model.
Рис. 4.6. Выбор режима слияния моделей
Появляется диалог, в котором следует указать опции слияния модели (рис. 4.7).
При слиянии моделей объединяются и словари стрелок и работ. В случае одинаковых
определений возможна перезапись определений или принятие определений из моделиисточника. То же относится к именам стрелок, хранилищам данных и внешним ссылкам.
Рис. 4.7. Диалог Continue with merge?
После подтверждения слияния (кнопка ОК) модель-источник подсоединяется к
модели-цели, стрелка вызова исчезает, а работа, от которой отходила стрелка вызова,
становится декомпозируемой – к ней подсоединяется диаграмма декомпозиции первого
уровня модели-источника (рис. 4.8).
Рис. 4.8. Модель после слияния с моделью «Изготовление деталей»
Стрелки, касающиеся работы на диаграмме модели-цели, автоматически не
мигрируют в декомпозицию, а отображаются как неразрешенные. Их следует
туннелировать вручную. На рис. 4.9 показано, как выглядят модели в окне Model Explorer
после слияния. Стрелкой показано, что модель склеилась с работой.
Рис. 4.9. Вид моделей в Model Explorer после слияния
В процессе слияния модель-источник остается неизменной и к модели-цели
подключается фактически ее копия. Не нужно путать слияние моделей с синхронизацией.
Если в дальнейшем модель-источник будет редактироваться, эти изменения
автоматически не попадут в соответствующую ветвь модели-цели.
Задание на лабораторную работу
1. В модели, используемой в лабораторной работе 3 расщепите работу «Сборка и
тестирование компьютеров» и создайте отщепленную модель «Сборка и тестирование
компьютеров»
2. Создайте в модели «Сборка и тестирование компьютеров» новую стрелку
«Неисправные компоненты». На диаграмме А0 это будет граничная стрелка выхода, на
диаграмме А0 − граничная стрелка выхода от работ «Сборка настольных компьютеров»,
«Тестирование компьютеров» и «Сборка ноутбуков».
3. Продемонстрируйте результаты расщепления модели преподпвателю.
4. Склейте новую модель «Сборка и тестирование компьютеров» с моделью
«Деятельность компании».
5. Неразрешенную граничную стрелку «Неисправные компоненты» направьте эту
стрелку к входу работы «Отгрузка и получение».
6. Продемонстрируйте результаты слияния моделей преподавателю.
Вопросы для самопроверки
1.
2.
3.
4.
5.
Для чего используют слияния и расщепления моделей?
Можно ли отщепить недекомпозированную работу?
Какие условия необходимо выполнить для слияния моделей?
Может ли стрелка вызова выходить из декомпозированной работы?
Может ли модель-источника быть недекомпозированной?
Лабораторная работа 5.
Созданной модели процессов в виде организационных диаграмм DFD
Цель работы: Изучить методы построения
организационных диаграмм DFD и Workflow (IDEF3).
модели
процессов
в
виде
Основные сведения
Диаграммы потоков данных (Data Flow Diagramming)
Диаграммы потоков данных (Data flow diagramming, DFD) используются для
описания документооборота и обработки информации. Подобно IDEF0, DFD
представляет модельную систему как сеть связанных между собой работ. Их можно
использовать как дополнение к модели IDEF0 для более наглядного отображения текущих
операций документооборота в корпоративных системах обработки информации.
Диаграмма потоков данных DFD описывает:
ппппп)
функции обработки информации (работы);
ррррр)
документы (стрелки, arrow), объекты, сотрудников или
отделы, которые участвуют в обработке информации;
ссссс)
внешние
ссылки
(external
references),
которые
обеспечивают интерфейс с внешними объектами, находящимися за
границами моделируемой системы;
ттттт)
таблицы для хранения документов (хранилище данных,
data store).
В BPwin для построения диаграмм потоков данных используется нотация ГейнаСарсона.
Для того чтобы дополнить модель IDEF0 диаграммой DFD, нужно в процессе
декомпозиции в диалоге Activity Box Count «кликнуть» по радиокнопке DFD. В палитре
инструментов на новой диаграмме DFD появляются новые кнопки:
ууууу)
- добавить в диаграмму внешнюю ссылку (External
Reference). Внешняя ссылка является источником или приемником
данных извне модели;
ффффф)
- добавить в диаграмму Что описывают стрелки (Data
store). Хранилище данных позволяет описать данные, которые
необходимо сохранить в памяти прежде, чем использовать в
работах.
Стрелки и объекты диаграммы DFD
В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи,
стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к
другой. Это представление потоков совместно с хранилищами данных и внешними
сущностями делает модели DFD более похожими на физические характеристики системы
– движение объектов (data flow), хранение объектов (data stores), поставка и
распространение объектов (external entities) (рис. 5.1).
Рис. 5.1. Пример диаграммы DFD
В отличие от IDEF0, где система рассматривается как взаимосвязанные работы,
DFD рассматривает систему как совокупность предметов. Контекстная диаграмма часто
включает работы и внешние ссылки. Работы обычно именуются по названию системы,
например «Система обработки информации». Включение внешних ссылок в
контекстную диаграмму не отменяет требования методологии четко определить цель,
область и единую точку зрения на моделируемую систему.
Работы. В DFD работы представляют собой функции системы, преобразующие
входы в выходы. Хотя работы изображаются прямоугольниками со скругленными углами,
смысл их совпадает со смыслом работ IDEF0 и IDEF3. Так же как работы IDEF3, они
имеют входы и выходы, но не поддерживают управления и механизмы, как IDEF0.
Внешние сущности. Внешние сущности изображают входы в систему и/или
выходы из системы. Внешние сущности изображаются в виде прямоугольника с тенью и
обычно располагаются по краям диаграммы. Одна внешняя сущность может быть
использована многократно на одной или нескольких диаграммах. Обычно такой прием
используют, чтобы не рисовать слишком длинных и запутанных стрелок.
Стрелки (Потоки данных). Стрелки описывают движение объектов из одной
части системы в другую. Поскольку в DFD каждая сторона работы не имеет четкого
назначения, как в IDEF0, стрелки могут подходить и выходить из любой грани
прямоугольника работы. В DFD также применяются двунаправленные стрелки для
описания диалогов типа «команда-ответ» между работами, между работой и внешней
сущностью и между внешними сущностями (рис. 5.2).
Хранилище данных. В отличие от стрелок, описывающих объекты в движении,
хранилища данных изображают объекты в покое (рис. 5.3).
Рис. 5.2. Внешняя сущность
Рис. 5.3. Хранилище данных
В материальных системах хранилища данных изображаются там, где объекты
ожидают обработки, например в очереди. В системах обработки информации хранилища
данных являются механизмом, который позволяет сохранить данные для последующих
процессов.
Слияние и разветвление стрелок. В DFD стрелки могут сливаться и
разветвляться, что позволяет описать декомпозицию стрелок. Каждый новый сегмент
сливающейся или разветвляющейся стрелки может иметь собственное имя.
Построение диаграмм DFD.
Диаграммы DFD могут быть построены с использованием традиционного
структурного анализа, подобно тому, как строятся диаграммы IDEF0. Сначала строится
физическая модель, отображающая текущее состояние дел. Затем эта модель
преобразуется в логическую модель, которая отображает требования к существующей
системе. После этого строится модель, отображающая требования к будущей системе. И,
наконец, строится физическая модель, на основе которой должна быть построена новая
система.
Альтернативным подходом является подход, популярный при создании
программного обеспечения, называемый событийным разделением (event partitioning), в
котором различные диаграммы DFD выстраивают модель системы. Во-первых,
логическая модель строится как совокупность работ и документирования того, что они
(эти работы) должны делать.
Затем модель окружения (environment model) описывает систему как объект,
взаимодействующий с событиями из внешних сущностей. Модель окружения обычно
содержит описание цели системы, одну контекстную диаграмму и список событий.
Контекстная диаграмма содержит один прямоугольник работы, изображающий систему в
целом, и внешние сущности, с которыми система взаимодействует.
Наконец, модель поведения (behavior model) показывает, как система обрабатывает
события. Эта модель состоит из одной диаграммы, в которой каждый прямоугольник
изображает каждое событие из модели окружения. Хранилища могут быть добавлены для
моделирования данных, которые необходимо запоминать между событиями. Потоки
добавляются для связи с другими элементами, и диаграмма проверяется с точки зрения
соответствия модели окружения.
Полученные диаграммы могут быть преобразованы с целью более наглядного
представления системы, в частности работы на диаграммах могут быть декомпозированы.
Нумерация объектов. В DFD номер каждой работы может включать префикс,
номер родительской работы (А) и номер объекта. Номер объекта – это уникальный номер
работы на диаграмме. Например, работа может иметь номер А.12.4. Уникальный номер
имеют хранилища данных и внешние сущности независимо от их расположения на
диаграмме. Каждое хранилище данных имеет префикс D и уникальный номер, например
D5. Каждая внешняя сущность имеет префикс Е и уникальный номер, например Е5.
Задание на лабораторную работу
При оформлении заказа важно проверить, существует ли такой клиент в базе
данных и, если не существует, внести его в базу данных и затем оформить заказ.
Оформление заказа начинается со звонка клиента. В процессе оформления заказа база
данных клиентов может просматриваться и редактироваться. Заказ должен включать
как информацию о клиенте, так и информацию о заказанных продуктах. Оформление
заказа подразумевает чтение и запись информации о прочих заказах.
В процессе декомпозиции согласно правилам DFD необходимо преобразовать
граничные стрелки во внутренние, начинающиеся и заканчивающиеся на внешних
ссылках.
1. Декомпозируйте работу «Оформление заказов» на диаграмме А1 на две работы.
2. Для новых работ определите имена:
ххххх)
ццццц)
«Формирование заказа»;
«Проверка и ввод клиентов».
3. Добавьте на диаграмму следующие хранилища данных:
ччччч)
«Список клиентов»;
шшшшш) «Список компонентов»;
щщщщщ) «Список заказов».
Работа «Проверка и ввод клиентов» взаимодействует с хранилищем данных
«Список клиентов» для ввода в него информации о новых клиентах и для получения
информации о зарегистрированных клиентах
Работа «Формирование заказа» взаимодействует с хранилищем данных «Список
клиентов» для получения информации о зарегистрированных клиентах, с хранилищем
данных «Список компонентов» для получения информации об имеющихся на складе
компонентах для сборки компьютеров и с хранилищем данных «Список заказов», в
котором хранятся существующие заказы клиентов и запоминаются вновь
сформированные заказы.
4. Добавьте на диаграмму внешнюю сущность «Звонки клиентов», которая
моделирует поступающую извне информацию на вход работ «Проверка и ввод клиентов»
и «Формирование заказа». Для работы «Формирование заказа» входом являются «Заявки
на заказ».
5. В результате формирования DFD диаграммы должна получиться диаграмма,
представленная на рис. 5.4.
Рис. 5.4. Диаграмма декомпозиции DFD
Обратите внимание, что стрелки «Информация о клиентах» и «Заказы клиентов»
двунаправленные. Кроме того, на родительской диаграмме А1 стрелки, подходящие и
исходящие из работы «Оформление заказов» станут туннелированными (рис. 5.5).
Рис. 5.5 – Работа «Оформление заказов» на диаграмме А1
Вопросы для самопроверки
Какое назначение имеют диаграммы DFD?
Что описывают диаграммы потоков данных DFD?
Что описывают внешние ссылки на диаграммах потоков данных DFD?
Для чего предназначены хранилища данных на диаграммах потоков данных
DFD?
5. Что представляют работы на диаграммах потоков данных DFD?
6. Что описывают стрелки на диаграммах потоков данных DFD?
7. Для чего в диаграммах DFD применяются двунаправленные стрелки?
1.
2.
3.
4.
Лабораторная работа 6.
Созданной модели информационных потоков в виде диаграмм Workflow
(IDEF3)
Цель работы: Изучить методы построения модели процессов (информационных
потоков) в виде диаграмм Workflow (IDEF3).
Основные сведения
Метод описания процессов IDEF3
Наличие в диаграммах DFD элементов для описания источников, приемников и
хранилищ данных позволяет более эффективно и наглядно описать процесс
документооборота. Однако для описания логики взаимодействия информационных
потоков более подходит IDEF3, называемая также workflow diagramming – методологией
моделирования, использующая графическое описание информационных потоков,
взаимоотношений между процессами обработки информации и объектов, являющихся
частью этих процессов. Диаграммы Workflow могут быть использованы в моделировании
бизнес-процессов для анализа завершенности процедур обработки информации. С их
помощью можно описывать сценарии действий сотрудников организации, например
последовательность обработки заказа или события, которые необходимо обработать за
конечное время. Каждый сценарий сопровождается описанием процесса и может быть
использован для документирования каждой функции.
IDEF3 – это метод, имеющий основной целью дать возможность аналитикам
описать ситуацию, в которой процессы выполняются в определенной последовательности,
а также описать объекты, участвующие совместно в одном процессе.
Техника описания набора данных IDEF3 является частью структурного анализа. В
отличие от некоторых методик описаний процессов IDEF3 не ограничивает аналитика
чрезмерно жесткими рамками синтаксиса, что может привести к созданию неполных или
противоречивых моделей.
Модель IDEF3 может использоваться как метод создания процессов. Каждая
работа в IDEF3 описывает какой-либо сценарий бизнес-процесса и может являться
составляющей другой работы. Поскольку сценарий описывает цель и рамки модели,
важно, чтобы работы именовались отглагольным существительным, обозначающим
процесс действия, или фразой, содержащей такое существительное.
Точка зрения на модель должна быть задокументирована. Обычно это точка зрения
человека, ответственного за работу в целом. Также необходимо задокументировать цель
модели − те вопросы, на которые призвана ответить модель.
Диаграммы IDEF3
Диаграмма является основной единицей описания в IDEF3. Важно правильно
построить диаграммы, поскольку они предназначены для чтения другими людьми (а не
только автором).
Единицы работы − Unit of Work (UOW). UOW, также называемые работами
(activity), являются центральными компонентами модели. В IDEF3 работы изображаются
прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным
существительным, обозначающим процесс действия, одиночным или в составе фразы, и
номер (идентификатор); другое имя существительное в составе той же фразы обычно
отображает основной выход (результат) работы (например, «Изготовление изделия»).
Часто имя существительное в имени работы меняется в процессе моделирования,
поскольку модель может уточняться и редактироваться. Идентификатор работы
присваивается при создании и не меняется никогда. Даже если работа будет удалена, ее
идентификатор не будет вновь использоваться для других работ. Обычно номер работы
состоит из номера родительской работы и порядкового номера на текущей диаграмме.
Работа в IDEF3 требует более подробного описания, чем работа в IDEF0. Каждая
UOW должна иметь ассоциированный документ, который включает текстовое описание
компонентов работы: объектов (Objects) и фактов (Facts), связанных с работой,
ограничений (Constraints), накладываемых на работу, и дополнительное описание работы
(Description). Эта информация заносится во вкладку UOW диалога Activity Properties
(рисунок 5.1).
Рисунок 6.1. Вкладка UOW диалога Activity Properties
Пример значений свойств UOW приведен в таблице 6.1.
Таблица 6.1. Пример текстового описания компонентов UOW
Тип
Использование
Name
Подготовка компонентов
Definition
Подготавливаются все компоненты компьютера согласно спецификации заказа
Objects
Constrains
Компоненты: корпус, материнская плата, жесткий диск, гибкий диск, видеокарта, оперативная
память, модем, программное обеспечение
Установка модема требует установки драйвера модема
Связи. Связи показывают взаимоотношения работ. Все связи в IDEF3
однонаправлены и могут быть направлены куда угодно, но обычно диаграммы IDEF3
стараются построить так, чтобы связи были направлены слева направо. В IDEF3
различают три типа стрелок, изображающих связи, стиль которых устанавливается во
вкладке Style (рис. 6.2) диалога Arrow Properties (пункт контекстного меню Style).
Рис. 6.2. Вкладка Style диалога Arrow Properties
Старшая стрелка (Precedence)– сплошная линия, связывающая единицы работ
(UOW). Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна
закончиться прежде, чем работа-цель начнется.
Стрелка отношения (Relational Link) – пунктирная линия, использующаяся для
изображения связей между единицами работ (UOW), а также между единицами работ и
объектами ссылок.
Потоки объектов (Object Flow) – стрелка с двумя наконечниками, применяется для
описания того факта, что объект используется в двух или более единицах работы,
например, когда объект порождается в одной работе и используется в другой.
Старшая связь и поток объектов. Старшая связь показывает, что работаисточник заканчивается ранее, чем начинается работа-цель. Часто результатом работыисточника становится объект, необходимый для запуска работы-цели. В этом случае
стрелку, обозначающую объект, изображают с двойным наконечником. Имя стрелки
должно ясно идентифицировать отображаемый объект. Поток объектов имеет ту же
семантику, что и старшая стрелка.
Отношение показывает, что стрелка является альтернативой старшей стрелке или
потоку объектов в смысле задания последовательности выполнения работ – работаисточник не обязательно должна закончиться прежде, чем работа-цель начнется. Более
того, работа-цель может закончиться прежде, чем закончится работа-источник (рис. 6.3).
Старт
работыисточника
Окончание
работыисточника
Старт
работы-цели
Старт
работыисточника
Старт
работы-цели
Окончание
работыисточника
Окончание
работы-цели
Старшая или
Поток объектов
Окончание
работы-цели
Отношение
Старт
работыисточника
Окончание
работы-цели
Старт
работы-цели
Окончание
работыисточника
Отношение
Рис. 6.3. Временная диаграмма выполнения работ
Перекрестки (Junction)
Окончание одной работы может служить сигналом к началу нескольких работ, или
же одна работа для своего запуска может ожидать окончания нескольких работ.
Перекрестки используются для отображения логики взаимодействия стрелок при слиянии
и разветвлении или для отображения множества событий, которые могут или должны
быть завершены перед началом следующей работы. Различают перекрестки для слияния
(Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может
использоваться одновременно для слияния и для разветвления. Для внесения перекрестка
служит кнопка
(добавить в диаграмму перекресток – Junction) в палитре
инструментов. В диалоге Junction Type Editor необходимо указать тип перекрестка. Смысл
каждого типа приведен в табл. 6.2.
Таблица 6.2. Типы перекрестков
Обо
значен
ие
Наименован
ие
Смысл в случае
слияния
стрелок
(Fan-in Junction)
Асинхронное
"И"
(Asynchronous AND)
Все
процессы
предшествующие
должны
Смысл в случае разветвления
стрелок (Fan-out Junction)
Все следующие процессы должны быть запущены
быть
завершены
Синхронное
(Synchronous AND)
"И"
Все
предшествующие
процессы
Все
следующие
процессы
запускаются
завершены одновременно
одновременно
Асинхронное
"ИЛИ"
OR)
Один
или
(Asynchronous предшествующих
несколько
Один или несколько следующих процессов должны
процессов быть запущены
должны быть завершены
Синхронное "ИЛИ"
(Synchronous OR)
Один
или
предшествующих
несколько
Один
или
несколько
следующих
процессов
процессов запускаются одновременно
завершены одновременно
Исключающее
Только
"ИЛИ" XOR (Exclusive предшествующий
OR)
один
Только один следующий процесс запускается
процесс
завершен
Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J.
Можно редактировать свойства перекрестка при помощи диалога Junction Properties
(вызывается из контекстного меню). В отличие от IDEF0 и DFD в IDEF3 стрелки могут
сливаться и разветвляться только через перекрестки. На рис. 6.4 представлен пример
применения перекрестка синхронное «И».
Рис. 6.4. Перекрестки для слияния и разветвления типа синхронного «И»
В данном случае после завершения работы 1 одновременно запускаются работы 2 и
4. Для запуска работы 5 требуется одновременное завершение работ 3 и 4
На рис. 6.5 представлен пример применения перекрестка асинхронное «И». После
завершения работы 1 запускаются работы 2 и 4 (не обязательно одновременно). Для
запуска работы 5 требуется завершение работ 3 и 4 (не обязательно одновременное)
Рис. 6.5. Перекрестки для слияния и разветвления типа асинхронного «И»
На рис. 6.6 представлен пример применения перекрестка асинхронное «ИЛИ».
После завершения работы 1 запускается либо работа 2, либо работа 3, либо работа 4, либо
их сочетание (не обязательно одновременно). Для запуска работы 5 требуется завершение
любой из работ 2, 3 и 4 или их сочетания (не обязательно одновременно).
Рис. 6.6. Перекрестки для слияния и разветвления типа асинхронного «ИЛИ»
На рис. 6.7 представлен пример применения перекрестка синхронное «ИЛИ».
После завершения работы 1 запускается либо работа 2, либо работа 3, либо работа 4, либо
их сочетание. Если запускается более одной работы, требуется их одновременный запуск.
Для запуска работы 5 требуется завершение любой из работ 2, 3 и 4 или их сочетания.
Если завершается более чем одна работа, требуется их одновременное завершение.
Рис. 6.7. Перекрестки для слияния и разветвления типа синхронного «ИЛИ»
На рис. 6.8 представлен пример применения перекрестка исключающее «ИЛИ».
После завершения работы 1 запускается только одна работа — либо работа 2, либо
работа 4. Для запуска работы 5 требуется завершение только одной из работ 3 или 4.
Рис. 6.8. Перекрестки для слияния и разветвления типа исключающего
«ИЛИ»
Правила создания перекрестков. На одной диаграмме IDEF3 может быть
создано несколько перекрестков различных типов. Определенные сочетания
перекрестков для слияния и для разветвления могут приводить к логическим
несоответствиям. Чтобы избежать конфликтов, необходимо соблюдать следующие
правила:
1. Каждому перекрестку для слияния должен предшествовать перекресток для
разветвления.
2. Перекресток для слияния «И» не может следовать за перекрестком для
разветвления типа синхронного или асинхронного «ИЛИ» (рис. 6.9). Действительно,
после работы 1 может запускаться только одна работа – 2 или 3, а для запуска работы 4
требуется окончание обеих работ – 2 и 3. Такой сценарий не может реализоваться.
Рис. 6.9. Неверное размещение перекрестков типа «И» и «ИЛИ»
3. Перекресток для слияния «И» не может следовать за перекрестком для
разветвления типа исключающего «ИЛИ» (рис. 6.10).
Рис. 6.10. Неверное размещение перекрестков исключающего «ИЛИ» и «И»
4. Перекресток для слияния типа исключающего «ИЛИ» не может следовать за
перекрестком для разветвления типа «И» (рис. 6.11). Здесь после завершения работы 1
запускаются обе работы – 2 и 3, а для запуска работы 4 требуется, чтобы завершилась
одна и только одна работа – или 2, или 3.
Рис. 6.11. Неверное размещение перекрестков типа «И» и исключающего
«ИЛИ»
5. Перекресток, имеющий одну стрелку на одной стороне, должен иметь более
одной стрелки на другой.
Объект ссылки
Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые
нельзя связать со стрелкой, перекрестком или работой (рис. 6.12).
Рис. 6.12. Объект ссылки
Для внесения объекта ссылки служит кнопка
(добавить в диаграмму объект
ссылки − Referent) в палитре инструментов. Объект ссылки изображается в виде
прямоугольника, похожего на прямоугольник работы. Имя объекта ссылки задается в
диалоге Referent Properties (пункт контекстного меню Name), в качестве имени можно
использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели
данных (на рис. 5.15 – имя объекта «Бухгалтерская система»). Объекты ссылки должны
быть связаны с единицами работ или перекрестками линиями без стрелок. Официальная
спецификация IDEF3 различает три стиля объектов ссылок:
ыыыыы) безусловные (unconditional);
эээээ)
синхронные (synchronous);
ююююю) асинхронные (asynchronous).
BPwin поддерживает только безусловные объекты ссылок. Синхронные и
асинхронные объекты ссылок, используемые в диаграммах переходов состояний
объектов, не поддерживаются.
При внесении объектов ссылок помимо имени следует указывать тип объекта
ссылки. Типы объектов ссылок приведены в таблице 6.3.
Декомпозиция работ. В IDEF3 декомпозиция используется для детализации
работ. Методология IDEF3 позволяет декомпозировать работу многократно, т.е. работа
может иметь множество дочерних работ. Это позволяет в одной модели описать
альтернативные потоки. Декомпозиция может быть сценарием или описанием. Описание
включает все возможные пути развития процесса. Сценарий является частным случаем
описания и иллюстрирует только один путь реализации процесса. По умолчанию при
декомпозиции на диаграмму IDEF3 создается описание. Чтобы создать сценарий,
необходимо перейти в меню Diagram/Add IDEF3 Scenario.
Таблица 6.3 – Типы объектов ссылок
Тип
Цель описания
объекта
ссылки
OBJECT
Описывает участие важного объекта в работе
Инструмент циклического перехода (в повторяющейся последовательности работ), возможно на
GOTO
текущей диаграмме, но не обязательно. Если все работы цикла присутствуют на текущей диаграмме,
цикл может также изображаться стрелкой, возвращающейся на стартовую работу. GOTO может
ссылаться на перекресток
Применятся, когда необходимо подчеркнуть множественное использование
UOB
(Unit of behavior)
какой-либо работы, но без цикла. Например, работа «Контроль качества» может
быть использована в процессе «Изготовление изделия» несколько раз, после каждой
единичной операции. Обычно этот тип ссылки не используется для моделирования
автоматически запускающихся работ
Используется для документирования важной информации, относящейся к каким-
NOTE
либо графическим объектам на диаграмме. NOTE является альтернативой внесению
текстового объекта в диаграмму
ELAB
(Elaboration)
Используется для усовершенствования графиков или их более детального
описания. Обычно употребляется для детального описания разветвления и слияния
стрелок на перекрестках
Возможность множественной декомпозиции предъявляет дополнительные
требования к нумерации работ. Так, номер работы состоит из номера родительской
работы, номера декомпозиции и собственного номера работы на текущей диаграмме (рис.
6.13).
Для описания номер декомпозиции равен 1. Для сценария номер декомпозиции
всегда больше 1.
Номер родительской
работы
Номер декомпозиции
Номер работы
А13.1.1
Рис. 6.13 – Номер единицы работы (UOW)
При создании сценария или описания необходимо придерживаться
дополнительных ограничений – в сценарии или декомпозиции может существовать только
одна точка входа. За точкой входа следует работа или перекресток. Для декомпозиции
может существовать только одна точка выхода. Сценарий, который не является
декомпозицией, может иметь несколько точек выхода.
Рассмотрим процесс декомпозиции диаграмм IDEF3, включающий взаимодействие
автора (аналитика) и одного или нескольких экспертов предметной области.
Описание сценария, области и точки зрения
Перед проведением сеанса экспертизы у экспертов предметной области должны
быть документированы сценарии и рамки модели для того, чтобы эксперт мог понять цели
декомпозиции. Для создания сценария используется пункт меню Diagram/Add IDEF3
Scenario. На сценарии удаляют все элементы, не входящие в сценарий. Кроме того, если
точка зрения моделирования отличается от точки зрения эксперта, она должна быть
особенно тщательно документирована.
Возможно, что эксперт самостоятельно не сможет передать необходимую
информацию. В этом случае аналитик должен приготовить список вопросов для
проведения интервью.
Определение работ и объектов. Обычно эксперт предметной области передает
аналитику текстовое описание сценария. В дополнение к этому может существовать
документация, описывающая интересующие процессы. Из всей этой информации
аналитик должен составить список кандидатов на работы (отглагольные
существительные, обозначающие процесс, одиночные или в составе фразы) и кандидатов
на объекты (существительные, обозначающие результат выполнения работы), которые
необходимы для перечисленных в списке работ.
В некоторых случаях целесообразно создать графическую модель для
представления ее эксперту предметной области. Графическая модель может быть также
создана после сеанса сбора информации для того, чтобы детали форматирования
диаграммы не смущали участников.
Поскольку разные фрагменты модели IDEF3 могут быть созданы разными
группами аналитиков в разнос время, IDEF3 поддерживает простую схему нумерации
работ в рамках всей модели. Разные аналитики оперируют разными диапазонами номеров,
работая при этом независимо. Пример выделения диапазона приведен в таблице 6.4.
Таблица 6.4. Диапазоны номеров работ
Аналитик
Диапазон номеров IDEF3
Иванов
1-999
Петров
1000-1999
Сидоров
2000-2999
Последовательность и согласование. Если диаграмма создается после
проведения интервью, аналитик должен принять некоторые решения, относящиеся к
иерархии диаграмм, например, сколько деталей включать в одну диаграмму. Если
последовательность и согласование диаграмм неочевидны, может быть проведена еще
одна экспертиза для детализации и уточнения информации. Важно различать
подразумевающее согласование (согласование, которое подразумевается в отсутствие
связей) и ясное согласование (согласование, ясно изложенное в мнении эксперта).
Работы, перекрестки и документирование объектов. IDEF3 позволяет внести
информацию в модель различными способами. Например, логика взаимодействия может
быть отображена графически в виде комбинации перекрестков. Та же информация может
быть отображена в виде объекта ссылки типа ELAB (Elaboration). Это позволяет
аналитику вносить информацию в удобном в данный момент времени виде. Важно
учитывать, что модели могут быть реорганизованы, например, для их представления в
более презентабельном виде. Выбор формата для презентации часто имеет важное
значение для организации модели, поскольку комбинация перекрестков занимает
значительное место на диаграмме и использование иерархии перекрестков затрудняет
расположение работ на диаграмме.
Задание на лабораторную работу
1. Декомпозируйте работу «Сборка настольных компьютеров» на четыре работы в
нотации IDEF3.
Для единицы работы 1 задайте имя работы «Подготовка компонентов» и
определение «Подготавливаются все компоненты компьютера согласно спецификации
заказа».
Задайте свойства работы в соответствии с табл. 6.1.
2. Добавьте на диаграмму еще 3 работы. Задайте имена работ:
яяяяя)
«Установка материнской платы и винчестера»;
аааааа)
«Установка модема»;
бббббб)
«Установка дисковода CD-ROM»;
вввввв)
«Установка флоппи- дисковода»;
гггггг)
«Инсталляция операционной системы»;
дддддд)
«Инсталляция
дополнительного
программного
обеспечения».
3. Создайте объект ссылки. Внесите имя объекта внешней ссылки
«Компоненты». Свяжите стрелкой объект ссылки и работу «Подготовка компонент».
4. Свяжите стрелкой работы «Подготовка компонентов» (выход) и «Установка
материнской платы и винчестера» Измените стиль стрелки на Object Flow.
5. Добавьте на диаграмму два перекрестка типа «асинхронное ИЛИ» (J1 и J2) и
свяжите работы с перекрестками следующим образом:
ееееее)
выход работы «Установка материнской платы и
винчестера» с входом перекрестка J1;
жжжжжж) выход перекрестка J1 со входами работ «Установка
модема», «Установка дисковода CD-ROM» и «Установка флоппидисковода»;
зззззз)
выходы работ «Установка модема», «Установка дисковода
CD-ROM» и «Установка флоппи- дисковода» со входами
перекрестка J2;
ииииии) выход перекрестка J2 со входом работы «Инсталляция
операционной системы».
6. Создайте объект ссылки. Внесите имя объекта внешней ссылки «Программное
обеспечение». Свяжите линиями объект ссылки с работами «Инсталляция операционной
системы» и «Инсталляция дополнительного программного обеспечения».
7. Создайте два перекрестка типа «исключающего ИЛИ» (J3 и J4) и свяжите их с
работами следующим образом:
кккккк)
выход работы «Инсталляция операционной системы» с
входом перекрестка J3;
лллллл)
выход перекрестка J3 со входом работы «Инсталляция
дополнительного программного обеспечения» и входом перекрестка
J4;
мммммм) выход
работы
«Инсталляция
дополнительного
программного обеспечения» со входом перекрестка J4;
нннннн) для выхода перекрестка J4 создать граничную выходную
стрелку.
8. В результате формирования IDEF3 диаграммы должна получиться диаграмма,
представленная на рис. 6.14.
Рис. 6.14. Результат построения диаграммы IDEF3
9. Поясните преподавателю назначение диаграммы IDEF3, её элементов и
корректность применения переключателей для моделирования последовательности работ.
10. Создайте диаграмму сценария на основе диаграммы IDEF3 «Сборка
настольных компьютеров». В результате должен получиться сценарий, аналогичный
приведенному на рис. 6.15.
Рис. 6.15. Результат построения диаграммы сценария
Вопросы для самопроверки
1. Какое назначение имеют диаграммы IDEF3?
2. Какое назначение имеют единицы работ на диаграмме IDEF3?
3. Какие типы стрелок используются на диаграммах IDEF3?
4. Какие типы перекрестков используются на диаграммах IDEF3?
5. Какое имеет назначение перекресток асинхронное «И»?
6. Какое имеет назначение перекресток синхронное «И»?
7. Какое имеет назначение перекресток асинхронное «ИЛИ»?
8. Какое имеет назначение перекресток синхронное «ИЛИ»?
9. Какое имеет назначение перекресток исключающее «ИЛИ»?
10. Какие правила использования перекрестков необходимо соблюдать, чтобы
избежать конфликтов на диаграммах IDEF3?
11. Какие бывают стили объектов ссылок на диаграммах IDEF3?
12. Для чего используются сценарии диаграмм IDEF3?
Лабораторная работа 7.
Созданное организационных диаграмм и диаграмм Swim Lane
Цель работы: Изучить
организационных диаграмм.
методы
построения
многоуровневой
модели
Основные сведения
Организационные диаграммы
BPwin 4.0 содержит набор инструментов для моделирования организационной
структуры предприятия, в который входят четыре словаря:
оооооо)
пппппп)
рррррр)
сссссс)
словарь изображений (bitmap);
словарь ресурсов;
словарь ролей;
словарь групп ролей.
Словарь изображений служит для импорта файлов в формате bmp в модель.
Импортированные изображения можно использовать в диаграммах для улучшения их
внешнего вида. Для импорта изображения следует перейти в меню Dictionary/Bitmaps.
Появляется диалог Bitmap Dictionary (рис. 7.1).
Рис. 7.1. Диалог Bitmap Dictionary
Для добавления изображений, которые необходимо применять в проекте следует
щелкнуть по кнопке Import и найти файл формата bmp. Требуемые изображения следует
найти в существующих библиотеках или создать самостоятельно, например в
графическом редакторе MSPAIN. Пример сформированного словаря изображений,
используемого для моделирования различных стадий производственного процесса
приведен на рис. 7.2.
Рис. 7.2. Сформированный словарь изображений
Словарь Role Group Dictionary (меню Dictionary/Role Group, рис. 7.3) позволяет
создать и определить свойства групп ролей. Группы ролей могут использоваться как на
организационных диаграммах, так и на диаграммах Swim Lane. В качестве значения
группы ролей может быть название предприятия, отдела, цеха или название региона и т.д.
Рис. 7.3. Словарь групп ролей
Для каждой группы ролей может быть внесено описание, указано изображение,
предварительно импортированное в словаре изображений, и указана важность группы
ролей.
Словарь ролей вызывается из меню Dictionary/Role (рис. 7.4). Ролью может быть
должность или позиция конкретного исполнителя. Каждой роли может соответствовать
одна или несколько групп ролей. Обратите внимание, что начальник производства,
системный архитектор и инженер по сопровождению отнесены к двум группам ролей. Это
сделано для того, чтобы можно было формировать иерархию организационной структуры
предприятия.
Рис. 7.4. Словарь ролей
Так начальник производства подчиняется директору и поэтому включен в группу
ролей «управление», а с другой стороны он руководит производственным персоналом и
поэтому включен в группу ролей «Производство».
Кроме того, в словаре ролей для каждой роли можно внести определение
(Definition), связать роль с изображением (Bitmap) и геометрической фигурой (Shape),
указать важность роли (Importance).
Словарь ресурсов (меню Dictionary/Resource, рис. 7.5) позволяет создать ресурс и
связать его с комбинацией «группа ролей/роль». Ресурсом для роли может быть
конкретный исполнитель. В качестве значения ресурса, например, можно использовать
фамилию и имя сотрудника.
Рис. 7.5. Словарь ресурсов
На основе информации, внесенной в словари изображений, групп ролей, ролей и
ресурсов, можно создать организационную диаграмму. Организационная диаграмма
позволяет документировать и представить в виде дерева структуру организации
(например, штатное расписание и т. д.). Для создания организационной диаграммы
следует выбрать меню Diagram/Add Organization Chart. Появляется мастер Organization
Chart Wizard. В первом шаге мастера построения организационной диаграммы (рис. 7.6)
следует внести название и имя автора диаграммы, группу ролей и роль для верхнего
уровня иерархического дерева.
Рис. 7.6. Мастер построения организационной диаграммы. Шаг 1.
Второй шаг мастера (рис. 7.7) позволяет создать второй уровень иерархического
дерева. Верхний список содержит все доступные роли с ассоциированными ресурсами,
нижний − роли и ресурсы второго уровня иерархии. Кнопка Add позволяет перенести
роли и ресурсы из верхнего списка в нижний, кнопка Remove из нижнего в верхний.
Рис. 7.7. Мастер построения организационной диаграммы. Шаг 2.
Третий шаг мастера построения организационной диаграммы предназначен для
изменения свойств организационной диаграммы. В группе Drawing можно указать, какая
именно информация будет отображаться на блоках диаграммы (наименование блока, имя
группы ролей, роль и ресурс). Для отображения иконок на диаграмме в группе Draw Style
следует выбрать опцию Bitmap. После щелчка по кнопке Finish создается организационная
диаграмма (рис. 7.8).
Рис. 7.8. Первый и второй уровни организационной диаграммы
Для дополнения диаграммы следует щелкнуть правой кнопкой мыши по блоку
второго уровня и выбрать в контекстном меню один из пунктов:
тттттт)
редактирование блока (Edit subordinate list);
уууууу)
добавить нижний уровень (Add subordinates);
фффффф) добавить блок на текущий уровень слева
редактируемого блока (Add sibling on left);
хххххх)
добавить блок на текущий уровень справа
редактируемого блока (Add sibling on right).
от
от
Вначале добавим на диаграмму программиста-разработчика, который подчиняется
системному архитектору и получим диаграмму, представленную на рис. 7.9.
Рис. 7.9. Добавление третьего уровня организационной диаграммы
Далее добавим структурные единицы производственного отдела (инженер по
программному обеспечению, иВ результате редактирования организационной диаграммы
структура предприятия должна быть в виде, приведенном на рис. 7.10.
Рис. 7.10. Организационная диаграмма предприятия
Диаграммы Swim Lane
Созданные в словаре Role Dictionary роли могут быть использованы в диаграмме
Swim Lane. Диаграмма Swim Lane является разновидностью диаграммы IDEF3,
позволяющей явно описать роли и ответственности исполнителей в конкретной
технологической операции. Эта диаграмма разделена на горизонтальные полосы, с каждой
полосой может быть связана роль или UDP типа Text List. Полоса может содержать
объекты диаграммы IDEF3 (UOW, перекрестки и объекты ссылок), относящиеся к
соответствующей роли.
Для создания диаграммы Swim Lane следует выбрать меню Diagram/Add Swim Lane
diagram. Появляется мастер Swim Lane diagram Wizard. В первом шаге диалога мастера
(рис. 7.11) следует внести название и имя автора диаграммы, выбрать имя и номер
диаграммы IDEF3, на основе которой будет построена диаграмма, и группу ролей, из
которой можно будет выбрать роли, связанные с диаграммой.
На втором шаге диалога мастера следует выбрать роли, на основе которых будет
создана диаграмма. Диаграмма будет разделена на количество полос, указанных в колонке
Display Swim Line (рисунок 7.12).
После щелчка по кнопке Finish создается новая диаграмма, все объекты которой
расположены произвольно. Расположить объекты на полосах, соответствующих ролям,
следует вручную (рисунок 7.13).
Рис. 7.11. Первый шаг диалога мастера построения Swim Lane Diagram
Wizard
Рис. 7.12. Выбор ролей во втором шаге диалога мастера построения Swim
Lane Diagram Wizard
Рисунок 7.13 – Диаграмма Swim Lane
Задание на лабораторную работу
1. Сформируйте словарь изображений. Файлы .bmp можно найти в папке \Program
Files\Computer Associates\Erwin 4.0\Icons\ или подготовить самостоятельно с помощью
графического редактора.
2. Сформируйте словарь групп ролей. Словарь, приведенный на рис. 7.3,
желательно дополнить и видоизменить.
3. Сформируйте словарь ролей. Словарь, приведенный на рис. 7.4, необходимо
расширить.
4. Сформируйте словарь ресурсов. Словарь, приведенный на рис. 7.5, желательно
дополнить и видоизменить.
5. Построить организационную структуру предприятия.
6. Построить диаграммы Swim Lane для отображения распределения ролей при
сборке компьютеров.
7. Продемонстрировать результаты создания моделей преподавателю.
Вопросы для самопроверки
1.
2.
3.
4.
5.
6.
Какие словари используются для построения организационных диаграмм?
Для чего применяется словарь Role Group Dictionary?
Для чего применяется словарь Role Dictionary?
Какие имеются особенности формирования словаря Role Dictionary при
необходимости построения многоуровневой организационной диаграммы
предприятия?
Для чего применяется словарь Resource Dictionary?
Для чего применяются диаграммы Swim Lane?
Лабораторная работа 8.
Стоимостной анализ (Activity Based Costing)
Цель работы: Изучить методы стоимостного анализа.
Основные сведения
Стоимостный анализ (ABC)
При моделировании бизнес-процессов сначала строится функциональная модель
существующей организации работы − AS-IS (Как есть). После построения модели AS-IS
проводится анализ бизнес-процессов, потоки данных и объектов перенаправляются и
улучшаются, в результате строится модель ТО-ВЕ (Как должно быть). Как правило,
строится несколько моделей ТО-ВЕ, из которых по какому-либо критерию выбирается
наилучшая. Проблема состоит в том, что таких критериев много и непросто определить
важнейший. Для того чтобы определить качество созданной модели с точки зрения
эффективности бизнес-процессов, необходима система метрики, т.е. качество следует
оценивать количественно.
BPwin предоставляет аналитику два инструмента для оценки модели –
стоимостный анализ, основанный на работах (Activity Based Costing, ABC), и свойства,
определяемые пользователем (User Defined Properties, UDP). ABC является широко
распространенной методикой, используемой международными корпорациями и
государственными организациями для идентификации истинных движителей затрат в
организации.
Стоимостный анализ представляет собой соглашение об учете, используемое для
сбора затрат, связанных с работами, с целью определить общую стоимость процесса.
Стоимостный анализ основан на модели работ, потому что количественная оценка
невозможна без детального понимания функциональности предприятия. Обычно ABC
применяется для того, чтобы понять происхождение выходных затрат и облегчить выбор
нужной модели работ при реорганизации деятельности предприятия (Business Process Reengineering, BPR). С помощью стоимостного анализа можно решить такие задачи, как
определение действительной стоимости производства продукта, определение
действительной стоимости поддержки клиента, идентификация работ, которые стоят
больше всего (те, которые должны быть улучшены в первую очередь), обеспечение
менеджеров финансовой мерой предлагаемых изменений, и др.
ABC может проводиться только тогда, когда модель работы последовательная
(следует синтаксическим правилам IDEF0), корректная (отражает бизнес), полная
(охватывает всю рассматриваемую область) И стабильная (проходит цикл экспертизы без
изменений), другими словами, создание модели работы закончено.
ABC включает следующие основные понятия:
цццццц) объект затрат – причина, по которой работа выполняется,
обычно, основной выход работы, стоимость работ есть суммарная
стоимость объектов затрат;
чччччч)
движитель затрат – характеристики входов и управлений
работы, которые влияют на то, как выполняется и как долго длится
работа;
шшшшшш)центры затрат, которые можно трактовать как статьи
расхода.
При проведении стоимостного анализа в BPwin сначала задаются единицы
измерения времени и денег. Для задания единиц измерения следует вызвать диалог Model
Properties (меню Edit/Model Properties), вкладка ABC Units (рис. 8.1).
Рис. 8.1. Настройка единиц измерения валюты и времени
Если в списке выбора отсутствует необходимая валюта (например, рубль), ее
можно добавить. Символ валюты по умолчанию берется из настроек Windows. Диапазон
измерения времени в списке Unit of measurement достаточен для большинства случаев – от
секунд до лет.
Затем описываются центры затрат (cost centers). Для внесения центров затрат
необходимо вызвать диалог Cost Center Dictionary (меню Dictionary/Cost Center (рис. 8.2).
Рис. 8.2. Справочник центров затрат
Каждому центру затрат следует дать подробное описание в окне Definition. Список
центров затрат упорядочен. Порядок в списке можно менять при помощи стрелок,
расположенных справа от списка. Задание определенной последовательности центров
затрат в списке, во-первых, облегчает последующую работу при присвоении стоимости
работам, а во-вторых, имеет значение при использовании единых стандартных отчетов в
разных моделях. BPwin сохраняет информацию о стандартном отчете в файле
BPWINRPT.INI, информация о центрах затрат и UDP сохраняется в виде указателей, т.е.
хранятся не названия центров затрат, а их номера. Поэтому, если нужно использовать
один и тот же стандартный отчет в разных моделях, списки центров затрат должны быть в
них одинаковы.
Для задания стоимости работы (для каждой работы на диаграмме декомпозиции)
следует щелкнуть правой кнопкой мыши по работе и на всплывающем меню выбрать
Costs (рис. 8.3).
Рис. 8.3. Задание стоимости работ в диалоге Activity Cost
Во вкладке Costs диалога Activity Properties указывается частота проведения
данной работы в рамках общего процесса (окно Frequency) и продолжительность
(Duration). Затем следует выбрать в списке один из центров затрат и в окне Cost задать его
стоимость. Аналогично назначаются суммы по каждому центру затрат, т. е. задается
стоимость каждой работы по каждой статье расхода. Если в процессе назначения
стоимости возникает необходимость внесения дополнительных центров затрат, диалог
Cost Center Editor вызывается прямо из диалога Activity Cost соответствующей кнопкой.
Общие затраты по работе рассчитываются как сумма по всем центрам затрат. При
вычислении затрат вышестоящей (родительской) работы сначала вычисляется
произведение затрат дочерней работы на частоту работы (число раз, которое работа
выполняется в рамках проведения родительской работы), затем результаты складываются.
Если во всех работах модели включен режим Compute from Decompositions, подобные
вычисления автоматически проводятся по всей иерархии работ снизу вверх (рис. 8.4).
Рис. 8.4. Вычисление затрат родительской работы
Этот достаточно упрощенный принцип подсчета справедлив, если работы
выполняются последовательно. Встроенные возможности BPwin позволяют разрабатывать
упрощенные модели стоимости, которые, тем не менее, оказываются чрезвычайно
полезными для предварительной оценки затрат. Если схема выполнения более сложная
(например, работы производятся альтернативно), можно отказаться от подсчета и задать
итоговые суммы для каждой работы вручную (Override Decompositions). В этом случае
результаты расчетов с нижних уровней декомпозиции будут игнорироваться, при расчетах
на верхних уровнях будет учитываться сумма, заданная вручную. На любом уровне
результаты расчетов сохраняются независимо от выбранного режима, поэтому при
выключении опции Override Decompositions расчет снизу вверх производится обычным
образом.
Для
проведения
более
тонкого
анализа
можно
воспользоваться
специализированным средством стоимостного анализа EasyABC (ABC Technology, Inc.).
BPwin имеет двунаправленный интерфейс с EasyABC. Для экспорта данных в EasyABC
следует выбрать пункт меню File/Export/Node Tree, задать в диалоге Export Node Tree
необходимые настройки и экспортировать дерево узлов в текстовый файл (.txt). Файл
экспорта можно импортировать в EasyABC. После проведения необходимых расчетов
результирующие данные можно импортировать из EasyABC в BPwin. Для импорта нужно
выбрать меню File/Import/Costs и в диалоге Import Activity Costs выбрать необходимые
установки.
Результаты стоимостного анализа могут существенно повлиять на очередность
выполнения работ. Рассмотрим пример, изображенный на рисунке 9.6. Предположим, что
для оценки качества изделия необходимо провести три работы:
щщщщщщ)внешний осмотр-стоимость 50 руб.;
ыыыыыы) пробное включение – стоимость 150 руб.;
ээээээ)
испытание на стенде – стоимость 300 руб.
Предположим также, что с точки зрения технологии очередность проведения работ
несущественна, а вероятность выявления брака одинакова (50 %). Пусть необходимо
проверить восемь изделий. Если проводить работы в убывающем по стоимости порядке,
то стоимость, затраченная на получение готового изделия, составит:
юююююю) 300 руб. (Испытание на стенде) (8+150 руб. (Пробное
включение) (4 + 50 руб. (Внешний осмотр) (2 = 3100 руб.
яяяяяя)
Если проводить работы в возрастающем по стоимости
порядке, то стоимость, затраченная на получение готового изделия,
составит:
ааааааа)
50 руб. (Внешний осмотр) (8+150 руб. (Пробное
включение) (4 + 300 руб. (Испытание на стенде) (2 = 1600 руб.
Следовательно, с целью минимизации затрат первой должна быть выполнена
наиболее дешевая работа, затем – средняя по стоимости и в конце – наиболее дорогая
(рис. 8.5).
Рис. 8.5. Фрагмент диаграммы декомпозиции работы «Контроль качества»
Результаты стоимостного анализа наглядно представляются на специальном отчете
BPwin – Activity Cost Report (меню Tools/Report/Activity Cost Report) Отчет позволяет
документировать имя, номер, определение и стоимость работ как суммарную, так и
раздельно по центрам затрат (рис. 8.6).
Рис. 8.6. Диалог настройки отчета по стоимости работ
Результаты отображаются и непосредственно на диаграммах. В левом нижнем углу
прямоугольника работы может показываться либо стоимость (по умолчанию), либо
продолжительность, либо частота проведения работы. Настройка отображения
осуществляется в диалоге Model Properties (меню Model/Model Properties), вкладка
Display, опции ABC Data и ABC Units.
Для просмотра отчета используется кнопка «Preview» (рис.8.7), для сохранения в
текстовом формате − «Report», для печати – «Print».
Рис. 8.7. Представление отчета на экране
Свойства, определяемые пользователем (UDP)
ABC позволяет оценить стоимостные и временные характеристики системы. Если
стоимостных показателей недостаточно, имеется возможность внесения собственных
метрик − свойств, определенных пользователем (User Defined Properties, UDP). UDP
позволяют провести дополнительный анализ, хотя и без суммирующих подсчетов.
Для описания UDP служит диалог UDP Dictionary (меню Dictionary/UDP) (рис.
8.8).
Рис. 8.8. Справочник свойств, определенных пользователем – UDP
UDP можно поставить в соответствие одно или несколько ключевых слов.
Ключевые слова могут быть использованы для отбора UDP при печати отчетов или при
присвоении свойств работам и стрелкам. Ключевые слова должны быть описаны в словаре
UDP Keyword List (рис. 8.9). Для внесения нового ключевого лова следует щелкнуть по
кнопке
и в таблице диалога UDP Keyword List задать значение ключевого слова.
Рис. 8.9. Справочник ключевых слов UDP
Для создания нового свойства (UDP) следует в словаре UDP Dictionary необходимо
перейти к нижней строке списка и дважды щелкнуть по полю Name. В режиме
редактирования имени следует внести имя UDP. В поле UDP Datatype (рис. 8.8)
описывается тип свойства, которое выбирается из выпадающего списка. Имеется
возможность задания 18 различных типов UDP (табл. 8.1), в том числе управляющих
команд и массивов.
Таблица 8.1. Типы UDP и их использование
Тип
Использование
1
2
При задании свойства стрелки или работы просто вносится текст, например, это может быть
Text
просто дополнительное пояснение
Paragraph Text
Значение свойства этого типа – текст в несколько строк
Integer
Значение свойства этого типа – целое число, например значение свойства «Количество баллов»
Командная строка. При задании значения UDP в списке свойств справа от имени свойства
появляется кнопка
Command
. При щелчке по этой кнопке выполняется командная строка. С помощью
этого свойства можно связать с объектом модели документацию, хранящуюся в формате
приложения Windows, например Word, Excel и т. д.
Character
Значение свойства этого типа – один символ
Date mm/dd/yy (УУ)
Значение свойства этого типа – дата
Значение свойства этого типа – действительное число, например значение свойства
Real Number
Text
«Потребление электроэнергии, кВт-ч»
List
(Single selection)
Integer
Массив строк. Значения свойства этого типа должны быть определены в диалоге UDP Dictionary
(поле Value). Объекту модели можно присваивать только одно значение из предварительно
заданного списка
List
(Single selection)
Массив целых чисел. Значения свойства этого типа должны быть определены в диалоге UDP
Dictionary (поле Value). Объекту модели можно присваивать только одно значение из
предварительно заданного списка
Массив команд. Значения свойства этого типа должны быть определены в диалоге UDP
Dictionary (поле Value). Объекту модели можно присваивать только одно значение из
Command List
предварительно заданного списка
Массив дат. Значения свойства этого типа должны быть определены в диалоге UDP Dictionary
Date List
mm/dd/yy(yy)
(поле Value). Объекту модели можно присваивать только одно значение из предварительно
(Single selection)
заданного списка
Real
Number
List
(Single selection)
Character
(Single selection)
Массив действительных чисел. Значения свойства этого типа должны быть определены в
диалоге UDP Dictionary (поле Value). Объекту модели можно присваивать только одно значение из
предварительно заданного списка
List
Массив символов. Значения свойства этого типа должны быть определены в диалоге UDP
Dictionary (поле Value). Объекту модели можно присваивать только одно значение из
предварительно заданного списка
Продолжение табл. 8.1
1
Text
2
List
Массив строк (множественный выбор). Значения свойства этого типа должны быть определены
(Multiple
в диалоге UDP Dictionary (поле Value). Объекту модели можно присваивать одновременно
selections)
несколько значений из предварительно заданного списка
Integer
List
Массив целых чисел (множественный выбор). Значения свойства этого типа должны быть
определены в диалоге UDP Dictionary (поле Value). Объекту модели можно присваивать
(Multiple selections)
одновременно несколько значений из предварительно заданного списка
Date
List
Массив дат (множественный выбор). Значения свойства этого типа должны быть определены в
диалоге UDP Dictionary (поле Value). Объекту модели можно присваивать одновременно несколько
(Multiple selections)
значений из предварительно заданного списка
Real
Number
List
Массив действительных чисел (множественный выбор). Значения свойства этого типа должны
(Multiple
быть определены в диалоге UDP Dictionary (поле Value). Объекту модели можно присваивать
selections)
одновременно несколько значений из предварительно заданного списка
Character
List
Массив символов (множественный выбор). Значения свойства этого типа должны быть
(Multiple
определены в диалоге UDP Dictionary (поле Value). Объекту модели можно присваивать
selections)
одновременно несколько значений из предварительно заданного списка
Для присвоения свойству ключевого слова следует перейти к полю Keyword и
выбрать из списка необходимые ключевые слова. Одному свойству может
соответствовать несколько разных ключевых слов, одно ключевое слово может
соответствовать разным свойствам.
Каждой работе можно поставить в соответствие набор UDP. Для этого следует
щелкнуть правой кнопкой мыши по работе и выбрать пункт меню UDP. Во вкладке UDP
Values диалога Activity Properties можно задать значения UDP. Свойства типа List
отображаются списком выбора, который заполнен предварительно определенными
значениями. Свойства типа Command могут иметь в качестве значения командную строку,
которая выполняется при нажатии на кнопку . Например, свойство «Спецификации»
категории «Дополнительная документация» может иметь значение WINWORD.EXE
sample1.doc (рис. 8.10).
Кнопка Filter служит для задания фильтра по ключевым словам UDP. По
умолчанию в списке показываются свойства всех категорий.
Кнопка Dictionary вызывает диалог User Defined Property Dictionary (рис. 8.11),
который позволяет создавать и редактировать как UDP, так и ключевые слова UDP. В
верхнем окне диалога вносится имя UDP, в списке выбора Datatype описывается тип
свойства. Для внесения ключевого слова следует задать имя в окне New Keywords и
щелкнуть по кнопке Add Keywords.
Рис. 8.10. Формирование свойств UDP Value
Рис. 8.11. Редактирование UDP и ключевых слов UDP Value
Для присвоения ключевого слова необходимо выбрать UDP из списка User-Defined
Properties, затем ключевое слово из списка Keywords и щелкнуть по кнопке Update. Одно
ключевое слово может объединять несколько свойств, в то же время одному свойству
может соответствовать несколько ключевых слов. Свойство типа List может содержать
массив предварительно определенных значений. Для определения области значений UDP
типа List следует задать значение свойства в окне New Member и щелкнуть по кнопке Add
Member. Значения из списка можно редактировать и удалять (кнопки Update Member и
Delete Member).
Рис. 8.12. Редактирование и формирование новых ключевых слов и значения
в списке List Member
Результат задания значений UDP можно проанализировать в отчете Diagram Object
Report (меню Tools/Report/Diagram Object Report, рис. 8.13).
В левом нижнем углу диалога настройки отчета показывается список UDP. С
помощью кнопки UDP Filters можно установить фильтр по ключевым словам.
На рис. 8.13 приведен фрагмент отчета.
Рис. 8.13. Диалог настройки отчета Diagram Object Report
Рис. 8.14. Фрагмент отчета Diagram Object Report
Задание на лабораторную работу
1. Установите единицы измерения денег и времени – рубли и часы.
2. Сформируйте название и определение центров затрат в соответствии с табл. 8.2.
Таблица 8.2. Центры затрат ABC
Центр
Определение
затрат
Затраты на управление, связанные с составлением графика работ, формированием партий
Управление
компьютеров, контролем над сборкой и тестированием
Рабочая сила
Затраты на оплату рабочих, занятых сборкой и тестированием компьютеров
Компоненты
Затраты на закупку компонентов
3. Для работ на диаграмме А2 – «Сборка и тестирование компьютеров» внесите
параметры ABC (табл. 8.3).
Таблица 8.3. Стоимости работ на диаграмме А2
Activity Name
Отслеживание
расписания
и
управление
сборкой и тестированием
Сборка
компьютеров
Сборка ноутбуков
Тестирование компьютеров
настольных
Cost
Cost
Center
Center
Duratio
n, день
Freque
ncy
Cost, руб.
500,00
1,00
1,00
Рабочая сила
100,00
1,00
12,00
Компоненты
16000,00
Рабочая сила
140,00
1,00
20,00
Компоненты
28000,00
Рабочая сила
60,00
1,00
32,00
Управление
Для работы А2 – «Сборка и тестирование компьютеров» в результат стоимость
работы должна составить 758420руб.
4. Сгенерируйте отчет Activity Cost Report. Вид отчета должен соответствовать,
приведенному на рис. 8.15.
Рис. 8.15. Отчет Activity Cost Report
5. Сформируйте ключевые слова UDP:
ббббббб)
ввввввв)
ггггггг)
«Расход ресурсов»;
«Документация»;
«Информационная система».
6. Создайте UDP «Приложение».
7. Для UDP задайте характеристики в соответствии с табл. 9.5
Таблица 9.5. Наименование и свойства UDP
Наименован
Тип
Значение
ие UDP
Ключевое
слово
Модуль оформления заказов
Модуль создания и контроля
Приложения
Text List
расписания выполнения работ.
(Multiple
Модуль учета комплектующих
Selection)
и оборудования.
Информационная
система
Модуль процедур сборки
и поиска неисправностей.
Winword.EXE samplel.doc
Дополнительная
Command
документация
List
История
Paragraph
изменения
Text
Загрязнение
Text List
окружаю-
(Single
щей среды
Selection)
Расход
Real
Расход
электроэнергии
Number
ресурсов
Winword.EXE sample2.doc
Документация
POWERPNT.EXE sample3.ppt
Документация
Очень высокое
Высокое
Среднее
Низкое
8. Назначте UDP работе «Сборка настольных компьютеров».
9. Внесите значения UDP для работ в соответствии с табл. 8.6
Таблица 8.6. Значения UDP
Дополн
Activity
Истори Расход Загрязнени
ительная
Name
я
Приложения
документ
электр
е
изменени оэнерг окружающ
ация
я
ии
ей среды
Модуль учета комплектующих и
Сборка настольных
оборудования. Модуль процедур
компьютеров
20,00
Среднее
25,00
Среднее
40,00
Среднее
10,00
Низкое
сборки и поиска неисправностей
Модуль учета комплектующих и
оборудования.
Сборка ноутбуков
Модуль
процедур
сборки
и
поиска неисправностей
Модуль учета комплектующих и
Тестирование
оборудования.
компьютеров
Модуль
процедур
сборки
и
поиска неисправностей
Отслеживание
расписания
и
управление сборкой
и тестированием
Win
word.EXE
sample2.doc
Модуль
создания
и
контроля
расписания выполнения работ
История
изменений
спецификаций
10. После внесения UDP типа Command или Command List щелчок по кнопке
приведет к запуску приложения.
11. Отключите ключевое слово «Информационная система». Убедитесь в
правильности режима фильтрации, который должен отключить UDP с ключевым
словом «Информационная система».
12. Постройте отчет по UDP для опци6
ддддддд) Start from Activity: A2. Сборка и тестирование
компьютеров;
еееееее) Number of Levels: 2;
жжжжжжж)
User Defined Properties: Расход электроэнергии.
Вопросы для самопроверки
1. Для чего используется стоимостной анализ?
2. Каким требованиям должна соответствовать модель работ для адекватного
проведения стоимостного анализа?
3. Целесообразно ли проводить стоимостной анализ, если модель работ
параллельная?
4. Целесообразно ли проводить стоимостной анализ, если модель работ не
корректная?
5. Целесообразно ли проводить стоимостной анализ, если модель работ не
полная?
6. Какие основные понятия включает стоимостной анализ ABC?
7. Как определяются объекты затрат в стоимостном анализе ABC?
8. Как определяются движители затрат в стоимостном анализе ABC?
9. Как определяются центры затрат в стоимостном анализе ABC?
10. Для чего применяются свойства, определяемые пользователем UDP?
Лабораторная работа 14.
Создание модели TO-BE (реинжиниринг бизнес-процессов)
Цель работы: Изучить методы реинжиниринг бизнес-процессов при построении
модели TO - BE (Как должно быть).
Реинжиниринг бизнес-процессов
Модель ТО-ВЕ создается на основе анализа модели AS-IS. Анализ может
проводиться как по формальным признакам (отсутствие выходов или управлений у работ,
отсутствие обратных связей и т. д.), так и по неформальным – на основе знаний
предметной области.
Допустим, в результате анализа принимается решение реорганизовать функции
производства и тестирования компьютеров и оставить функциональности «Продажи и
маркетинг» и «Отгрузка и получение» пока без изменений.
Принято решение сформировать отдел дизайна, который должен формировать
конфигурацию компьютеров, разрабатывать корпоративные стандарты, подбирать
приемлемых поставщиков, разрабатывать инструкции по сборке, процедуры
тестирования и устранения неполадок для всего производственного отдела.
Работа «Сборка и тестирование компьютеров» должна быть реорганизована
и названа «Производство продукта». Будут созданы работы «Разработать
конфигурацию», «Планировать производство» и «Собрать продукт».
Рассмотрим новые роли персонала. Дизайнер должен разрабатывать систему,
стандарты на продукцию, документировать и передавать спецификации в отдел
маркетинга и продаж. Он должен определять, какие компоненты (аппаратные и
программные) должны закупаться для сборки компьютеров, обеспечивать
документацией и управлять процедурами сборки, тестирования и устранения
неполадок.
Функции диспетчера в работе «Сборка и тестирование компьютеров» должны
быть заменены на функции планировщика.
Планировщик должен обрабатывать заказы клиентов и генерировать заказы на
сборку, получать коммерческий прогноз из отдела маркетинга и формировать
требования на закупку компонентов и собирать информацию от поставщиков.
Диспетчер должен составлять расписание производства на основании заказов на
сборку, полученных в результате работы «Планировать производство», получать
копии заказов клиентов и отвечать за упаковку и комплектацию заказанных
компьютеров, передаваемых в работу «Отгрузка и получение».
Задание на лабораторную работу
Расщепление и модификация модели
1. Измените свойства модели «Деятельность компании»:
ззззззз)
Model Name: Предлагаемая модель компании;
иииииии) Time Frame: TO-BE;
ккккккк) Purpose: Документировать предлагаемые
бизнес-процессов компании.
изменения
2. Переименуйте работу «Сборка и тестирование компьютеров» в «Производство
продукта». Расщепите эту работу в модель с тем же названием.
3. Модифицируйте отщепленную модель. Переместите работу «Тестирование
компьютеров» с диаграммы А0 «Производство продукта» на диаграмму А2.1 «Сборка
настольных компьютеров».
4. Переименуйте работу «Сборка настольных компьютеров» на диаграмме А0 в
«Сборку продукта».
5. Удалите работу «Сборка ноутбуков».
6. Переименуйте стрелку «Заказы на настольные компьютеры» в «Заказы на
изготовление».
7. Переименуйте «Отслеживание расписания и управление сборкой и
тестированием» в «Планирование производства».
8. Создайте работу «Разработать конфигурацию».
9. Создайте ветвь стрелки «Персонал производственного отдела», назовите ее
«Дизайнер» и направьте как механизм к работе «Разработать конфигурацию».
10. Создайте стрелку «Стандарты на продукцию» и направьте ее от выхода
«Разработать конфигурацию» к границе диаграммы. Туннелируйте эту стрелку
(Resolve Border Arrow). Создайте ветвь этой стрелки, идущую к управлению работы
«Планирование производства» и назовите ее «Списком необходимых компонентов» .
11. Удалите стрелку «Правила сборки и тестирования». Создайте ветвь стрелки
«Стандарты на продукцию», идущую к управлению работы «Сборка продукта» и
назовите ее «Правилами сборки и тестирования».
12. Переименуйте стрелку «Диспетчер» в «Планировщика производства».
13. Добавьте стрелку «Прогноз продаж» как граничную управляющую к работе
«Планирование производства» .
14. Добавьте стрелку «Информация от поставщика» как граничную управляющую
к работе «Планирование производства».
15. Добавьте стрелку «Заказ поставщику» как граничную стрелку выхода от
работы «Планирование производства» .
16. Туннелируйте эти стрелки (Resolve Border Arrow).
17. На диаграмме А0 туннелируйте стрелку (Resolve Border Arrow) «Собранные
компьютеры» и свяжите ее на диаграмме А0 с выходом работы «Сборка продукта».
Результат выполнения первой части лабораторной работы 9 приведен на рис. 9.1 и
9.2.
Рис. 9.1. Результат выполнения первой части лабораторной работы –
контекстная диаграмма
Рис. 9.2. Результат выполнения первой части работы – диаграмма А0
Слияние модели
1. Перейдите к работе «Производство продукта» в модели «Деятельность
компании». Осуществите слияние с ранее отщепленной моделью.
2. На диаграмме А0 туннелируйте стрелки (Resolve Border Arrow) «Информация от
поставщика» к «Заказ поставщику».
3. Направьте стрелку «Прогноз продаж» с выхода «Продажи и маркетинг» на
управление «Производство продукта».
4. Направьте стрелку «Стандарты на продукцию» с выхода «Производство
продукта» на управление «Продажи и маркетинг».
5. Удалите ветвь стрелки управления «Правила и процедуры» работы
«Производство продукта».
6. Закройте модель «Производство продукта».
Результат выполнения второй части лабораторной работы 9 приведен на рис. 9.3 и
9.4.
Рис. 9.3. Результат выполнения второй части работы – диаграмма А0
Рис. 9.4. Результат выполнения второй части работы – диаграмма АО
Использование Model Explorer для реорганизации дерева
декомпозиции
Существуют причины, по которым работа «Разработать конфигурацию»
должна быть на верхнем уровне, на диаграмме А0. Действительно, дизайнер
разрабатывает стандарты на продукцию, включая правила сборки и тестирования, и
список необходимых для закупки компонентов. Тем самым дизайнер управляет
производством продукта в целом, кроме того, управляет работой «Продажи и
маркетинг». Было бы логично перенести эту работу на уровень выше. Используя
возможности Model Explorer, перенесите работу «Разработать конфигурацию» с
диаграммы А2 «Производство продукта» на диаграмму А0.
Разрешите и перенаправьте стрелки согласно рисунку 9.5 и 9.6.
Рис. 9.5. Результат выполнения третьей части работы – диаграмма А0
Рис. 9.6. Результат выполнения третьей части работы – диаграмма A3
Модификация диаграммы IDEF3 «Сборка продукта» с целью
отображения новой информации
Так же как в модели AS-IS, сборка продукта состоит из сборки компонентов и
установки программного обеспечения. Однако теперь в работу «Сборка продукта»
включена работа «Тестирование компьютера».
Тестирование начинается после окончания процесса сборки компьютера и
окончания процесса установки программного обеспечения. Если компьютер неисправен,
в процессе тестирования у него заменяют компоненты, информация о неисправных
компонентах может быть направлена на работу «Подготовка компонентов». Такая
информация может помочь более тщательно подготавливать компоненты к сборке.
Результатом процесса тестирования являются заказанные компьютеры и неисправные
компоненты.
Модифицируйте диаграмму IDEF3 «Сборка продукта» в соответствии с
приведенной информацией. Результат приведен на рисунке 9.7.
Рис. 9.7. Результат выполнения четвертой части работы − диаграмма А32.1
Декомпозиция работы «Продажи и маркетинг»
Работа по продажам и маркетингу заключается в ответах на телефонные звонки
клиентов, предоставлении клиентам информации о ценах, оформлении заказов,
внесении заказов в информационную систему и исследовании рынка.
На основе этой информации декомпозируйте работу «Продажи и маркетинг»
(IDEF0).
Создайте следующие работы:
ллллллл) «Предоставление информации о ценах»;
ммммммм) «Оформление заказов»;
ннннннн) «Исследование рынка».
Результат декомпозиции представлен на рисунке 9.8.
Рис. 9.8. Результат выполнения пятой части работы – диаграмма А2
Вопросы для самопроверки
1. С какой целью проводится реинжиниринг бизнес-процессов?
2. По каким формальным признакам может проводиться реинжиниринг бизнеспроцессов?
3. По каким неформальным признакам может проводиться реинжиниринг бизнеспроцессов?
Библиографический список
1. Вендоров
А.М.
Проектирование
программного
обеспечения
экономических информационных систем: Учебник. – М.: Финансы и
статистика, 2000.
2. Маклаков С.В. BPwin и Erwin. CASE-средства разработки
информационных систем. – М.: ДИАЛОГ-МИФИ, 1999.
3. Маклаков С.В. Моделирование бизнес-процессов с BPwin 4.0. – М.:
ДИАЛОГ-МИФИ, 2002.
4. Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование
экономических информационных систем: Учебник. – М.: Финансы и
статистика, 2003.
ИНФОРМАЦИОННЫЙ МЕНЕДЖМЕНТ.
Моделирование бизнес-процессов
ЛАБОРАТОРНЫЙ ПРАКТИКУМ
Алексей Иванович Долженко
Николай Алексеевич Тимченко
Редактирование и корректура авторов
Ответственная за выпуск,
директор издательства
Изд. № 222/7681
Подписано к печати
Объем
уч. изд.–л.
Бумага офсетная. Печать офсетная. Гарнитура «Таймс» Формат 60  84/16
«C» 224
Отпечатано в