- глоссарий.
Для диаграмм, функциональных блоков, интерфейсных дуг IDEF0 подразумевает создание и поддержание набора соответствующих определений, ключевых слов, изложений, которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента.
Ограничения диаграмм.
Так как в IDEFO-модели отображается сложная и концентрированная информация, то, сделав ее удобочитаемой, рекомендуется придерживаться следующих ограничений:
- количество функциональных блоков на диаграмме - от 3 до 6:
- количество подходящих к одному функциональному блоку (выходящих из одного функционального блока) интерфейсных дуг - 4.
Коллективная работа.
Как правило, процесс разработки IDEFO-модели большой группой специалистов является итеративным и состоит из следующих условных этапов:
- создание группы специалистов, относящихся к различным сферам деятельности предприятия и называющихся авторами (Authors);
- создание черновика (Model Draft) модели на основе имеющихся положений, документов и результатов опросов;
- распространение черновика для рассмотрения, согласований и комментариев (до тех пор, пока авторы и читатели не придут к единому мнению);
- официальное утверждение модели, когда окончательная модель представляет собой согласованное представление о предприятии (системе) с заданной точки зрения и для заданной цели.
2.6 Инструментальные средства моделирования
Для системного и структурно-функционального анализа применяют так называемые инструментальные CASE-средства (Computer Aided Software/System Engineering), которые позволяют моделировать бизнес-процессы, базы данных, компоненты программного обеспечения, деятельность и структуру организаций на компьютере.
Инструментальные средства, предназначенные для моделирования информационных систем, могут быть отнесены к одной из следующих категорий:
- локальные, поддерживающие один тип моделей и методов (Design/IDEF, ProCap, S-Designor, «CASE. Аналитик»);
- малые интегрированные, поддерживающие несколько типов (до 5) моделей и методов (ERwin, BPwin);
- средние интегрированные, поддерживающие 5-15 типов моделей и методов (Rational Rose, Paradigm Plus, Designer/2000);
- крупные интегрированные, поддерживающие более 15 типов моделей и методов (ARIS Toolset).
Локальные средства моделирования могут быть использованы только на концептуальном уровне для предварительного анализа или как средство демонстрации заказчику общих предложений по будущему проекту. Задача комплексного анализа системы локальными средствами не может быть решена.
Характерными особенностями малых интегрированных средств моделирования является наличие в инструментальном средстве независимых компонентов и интеграция. Типичная сфера использования малых интегрированных средств - решение задач так называемой «лоскутной» автоматизации предприятия. Типичный представитель малых интегрированных средств моделирования - комплект программных продуктов Platinum Technology, основанный на пакетах BPwin (рис. 2.1) (новое название AIIFusion Process Modeler) (www.bpwin.ru)и ERwin (новое название AIIFusion ERwin Data Modeler) (www.erwin.ru).
Рис. 2.1 - Моделирование бизнес-процессов в среде BPwin
BPwin поддерживает 3 методологии моделирования (IDEFO, IDEF3 и DFD) и обеспечивает интеграцию моделей трех типов без экспорта или импорта данных. Интеграция выполняется как слиянием нескольких моделей, так и переключением на различные методологии в процессе разработки отдельных диаграмм модели. Предусмотрено расширение возможностей анализа систем как в самом пакете BPwin (функционально-стоимостный анализ), так и с помощью экспорта данных в другие пакеты. В ERwin поддерживается несколько разновидностей методологии информационного моделирования, основанной на ER-диаграммах («сущность-связь»).
При создании средних интегрированных средств моделирования в них были заложены требования комплексного использования различных методов и типов моделей. Продукты средней категории имеют единую среду для разработки всех поддерживаемых типов моделей, что позволяет применять одни и те же объекты в разных моделях. Так, например, последние версии Rational Rose позволяют строить восемь типов диаграмм UML:
- диаграммы прецедентов (Use Cases Diagrams);
- диаграммы классов (Class Diagrams);
- диаграммы последовательности (Sequence Diagrams);
- диаграммы сотрудничества (Collaboration Diagrams);
- диаграммы состояний (State Diagrams);
- диаграммы действий (Activity Diagrams);
- компонентные диаграммы (Component Diagrams);
- диаграммы развертывания (Deployment Diagram).
Пакет Paradigm Plus ориентирован на методологию OOCL (Object Oriented Change and Learning) и компонентную технологию проектирования и разработки, обеспечивая поддержку диаграмм различных методов (UML, CLIPP, TeamFusion, ОМТ, Booch, OOCL, Martin/Odell, Shlaer/ Mellor, Coad/Yourdon). В состав Designer/2000 входят Process Modeller (разработки моделей процессов) и System Modeller (модели иерархии функций (Function Hierarchy Diagrammer), модели потоков данных (Dataflow Diagrammer) и модели типа «сущность-отношение» (Entity Relationship Diagrammer)).
На сегодняшний день Rational Unified Process (RUP) - одно из самых известных решений от компании Rational Software. RUP является итеративным, т.е. создание продукта происходит за несколько итераций. В конце каждой итерации получается работающая версия продукта, но с неполным функционалом. В последующих итерациях функционал дорабатывается и в конце последней получается полностью готовый продукт.
Кроме того, RUP управляется сценариями пользователей (или прецедентами). Сценарий пользователя (Use Case) - это описание последовательности действий пользователя при выполнении определенной операции. Сценарии пользователей позволяют более точно представить разработчикам, что же должна делать система и как именно она должна это делать.
Процесс проектирования в RUP имеет четыре фазы: исследование (Inception), уточнение плана (Elaboration), построение (Construction) и развертывание (Transition). На каждой из фаз основное внимание уделяется разным процессам.
Методология RUP основана на 9 основных потоках:
1) бизнес-анализ;
2) сбор требований и управление требованиями;
3) анализ и моделирование;
4) кодирование;
5) тестирование;
6) управление конфигурацией и изменениями;
7) управление проектом;
8) создание и поддержка среды разработки;
9) развертывание.
Любой проект в RUP проходит четыре фазы, а через эти фазы проходят и все девять потоков. Каждая фаза, в свою очередь, разбивается на итерации.
Неотъемлемую часть RUP составляют артефакты и роли. Артефактом (Artefact) называется продукт, который создается и используется в процессе разработки ПО. За создание артефакта отвечает определенная роль. В RUP 2000, например, насчитывается более 30 ролей и более 50 артефактов.
RUP основывается на шести лучших практиках (best practices): итеративная разработка; управление требованиями; использование модульных архитектур; визуальное моделирование; проверка качества и отслеживание изменений.
Итеративная разработка позволяет на ранней стадии получить работающую версию продукта и выявить критичные недостатки. Благодаря управлению требованиями, программный продукт более точно соответствует ожиданиям заказчика. Визуальное моделирование позволяет эффективно бороться с возрастающей сложностью систем. Модели помогают понять, как на самом деле работает система, что она делает и как она это делает. Инструментальная поддержка проверки качества обеспечивается целым рядом программ: Rational Purify, Rational PureCoverage, Rational Quantify, Rational Robot. Отслеживание изменений позволяет оперативно реагировать на изменение требований заказчика либо на изменяющиеся условия внешней среды. Инструментальная поддержка обеспечивается Rational ClearCase и Rational ClearQuest.
К крупным интегрированным средствам моделирования относят систему, предназначенную для проектирования крупных АСУП класса ERP. Это семейство ARIS (ARIS Toolset, ARIS Easy Design) от компании IDS Sheer AG. Принадлежность к категории ERP для средства моделирования означает, что оно предназначено для выполнения комплексного анализа на всех стадиях разработки АСУП класса ERP.
ARIS обеспечивает четыре различных «взгляда» на моделирование и анализ:
- Процессы;
- Функции;
- Данные;
- Организация.
Для каждого «взгляда» поддерживаются три уровня анализа (требования, спецификации, внедрение). Каждый из уровней анализа состоит из своего комплекта моделей различных типов, в том числе диаграмм UML, диаграмм SAP/R3 и др. Каждый объект моделей ARIS имеет множество атрибутов, которые позволяют контролировать процесс разработки моделей, определять условия для выполнения функционально-стоимостного анализа, имитационного моделирования, взаимодействия с системами документооборота и т.д.
3. АСУП: Проблемы выбора и внедрения
3.1 Малый и большой реинжиниринг
В советское время наши ученые удивлялись тому, что на социалистическом предприятии никто не был заинтересован во внедрении экономико-математических методов, позволяющих выявить все производственные резервы и составить реальный план. Оказывается, тогда «благополучие» предприятия зависело от перевыполнения плана за счет утаенных резервов.
После обвала отечественной экономики в начале 90-х годов до автоматизации просто не было никакого дела, но уже по другим причинам. И, тем не менее, 3-4 года назад по мере ужесточения конкурентных условий началась и активная автоматизация отечественных предприятий, хотя для нее требовались дополнительные финансовые ресурсы. В силу объективных причин рыночной экономики, первыми смогли выделить необходимые финансовые средства на автоматизацию своих бизнес-процессов предприятия торговли и сферы услуг. Промышленность значительно отставала (кстати, отстает и сейчас) из-за длительного цикла оборачиваемости капитала, инертности мышления руководителей, государственного управления и некоторых других причин.
Этот вопрос содержит два аспекта - глобальный и локальный. Первый аспект связан с изменением ведения бизнеса в целом. Так вот, по оценкам экспертов, в ходе реорганизации компаний 90 % эффекта достигается за счет внедрения управленческих технологий и проведения реинжиниринга (см. раздел 1), в то время как автоматизация управления сама по себе дает не более 10 % эффективности. Поэтому основоположник реинжиниринга М. Хаммер призывал повышать эффективность бизнеса не столько за счет автоматизации, сколько за счет упрощения и устранения неэффективных звеньев.
Но беда заключается в том, что на реинжиниринг решаются очень мало предприятий. Это связано с их неготовностью к серьезным, а иногда и очень болезненным переменам. А вот автоматизация доступна большинству из них, так как это менее «болезненный» процесс. И тогда в качестве аргумента можно пользоваться другими цифрами. Так, согласно информации о западных компаниях, ERP-системы позволяют:
- снизить транспортно-заготовительные расходы на 60 %;
- сократить производственный цикл по заказным и базовым изделиям соответственно на 50 % и 30 %;
- снизить задержки с отгрузкой готовой продукции на 45 %;
- снизить производственный брак на 35 %;
- уменьшить затраты на административно-управленческий аппарат на 30%;
- уменьшить страховые запасы на 40 % и площадь складских площадей на 25 %;
- увеличить оборачиваемость средств в расчетах на 30 %;
- увеличить количество поставок точно в срок на 80 %.
Эти цифры, конечно же, впечатляют. Но не следует забывать и о стоимости таких решений, которая составляет от нескольких сотен тысяч до нескольких миллионов долларов. Получить же эффект в 3-4 раза меньший (для указанных выше цифр), но при стоимости на порядок, а иногда и на два порядка меньшей, позволяют и финансово-управленческие системы, претендующие на MRP-решения, на которых специализируются российские и украинские разработчики, и которые вполне «по карману» для отечественных предприятий.
3.2 Искусство внедрения АСУП
Искусство внедрения АСУП:
- автоматизация предприятия - это долгосрочная инвестиция;
- на автоматизацию надо решиться, глубоко осмыслив ее необходимость;
- нельзя автоматизировать то, чего нет (если на предприятии отсутствует система менеджмента как таковая, то нет и объекта автоматизации);
- не следует автоматизировать беспорядок, царящий на предприятии: кроме автоматизированного беспорядка, больше ничего не получится;
- автоматизация - это «ремонт», сопряженный с временными трудностями и удобствами в перспективе;
- «коробочные» решения приводят к «лоскутной» автоматизации, усложняя внедрение в дальнейшем интегрированной системы;
- нельзя игнорировать предпроектный анализ (сторонние консультанты «свежим» взглядом обнаружат все недостатки и непроизводительные бизнес-процессов);
- не пытайтесь разрабатывать собственную систему, все равно разработчики тиражных систем имеют гораздо больший опыт (это давно доказано мировой практикой);
- при выборе системы автоматизации нужно просмотреть как можно больше решений и, желательно, успешных;
- быть готовым к совершенствованию системы по мере развития ИТ и технологий ведения бизнеса;
- помнить о соотношении «80/20»: система автоматизации - это 80 % менеджмент и только 20 % технологии;
- автоматизация - это сложная и многогранная задача, поэтому не-обходимо отдавать высокий приоритет ее внедрению.
3.3 Два подхода к автоматизации