13. Анализ на базе семействаIdef

Анализ на базе семейства IDEF

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

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

Многие корпоративные информационные системы зарубежных производителей (SAP R/3, Baan, Ross iRenaissance и др.) имеют в своем составе специальные средства, основанные на собственных универсальных методиках. С помощью этих средств можно обследовать предприятие и построить модель их деятельности. Использование этих средств в нашей стране по вполне понятным причинам в на стоящее время затруднено. Однако существуют и стандартизированные методологии и инструментальные средства, прошедшие проверку временем, позволяющие решить эту задачу. К их числу и относятся стандарты семейства IDEF.

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

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

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

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

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

Диаграммы потоков данных (Data Flow Diagramming, DFD) используются для описания документооборота и обработки информации. Для описания логики взаимодействия информационных потоков более подходит нотация IDEF3 (workflow diagramming), - нотация моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектами, которые являются частью этих процессов.

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