Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Задачи и этапы предпроектного обследования).pdf

• инициатива (инициатор начала выполнения данной процедуры);

• контрагент (должность работника, который находится с обследуемым в контакте);

• отношение (отражающая субординацию агента и контрагента форма взаимодействия в данной процедуре);

• проблема (словесная характеристика решаемой проблемы).

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

• краткое схематичное описание бизнес-процессов (например: управление закупками и запасами, управление производством, управление продажами, управление финансовыми ресурсами);

• основные требования и приоритеты автоматизации;

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

• оценка возможности автоматизации, предложения по созданию автоматизированной системы с оценкой примерных сроков и стоимости.

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

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

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

Классификация бизнес процессов

Реализация процессного подхода требует четкой структуризации бизнес процессов. Первой попыткой классифицировать бизнес-процессы была разработка модели цепочки создания добавленной стоимости (Value Chain), предложенная Майклом Портером (табл.) в 1980 году. БП было предложено делить на основные и вспомогательные. Классификация М. Портера получила развитие в результате реализации норвежского проекта TOPP (The Productivity Program of the Technology Industry – программа повышения производительности промышленности) по сравнительному бенчмаркингу. Так же посредством бенчмаркинга Американский центр производительности и качества APQC (American Productivity & Quality Center) разработал кросс-отраслевую структуру классификации процессов PCF (Process Classification Framework). В настоящее время многие предприятия используют классификацию, предложенную в стандарте ГОСТ Р ИСО 9001-2008.

Подходы к классификации БП

Таблица 2.

По APQC делятся на 12 категорий (каждая категория разбивается на группы), из которых 5 категорий – операционные процессы, 7 – процессы управления и поддержки: категории операционных процессов (operating processes):

• разработка стратегии (Develop Vision and Strategy);

• разработка и управление продуктами и услугами (Develop and Manage Products and Services);

• рынок и продажа продуктов и услуг (Market and Sell Products and Services);

• доставка продуктов и услуг (Deliver Products and Services);

• управление обслуживанием клиентов (Manage Customer Service); категории процессов управления и поддержки (management and support services):

• разработка и поддержка человеческого капитала (Develop and Manage Human Capital);

• управление информационными технологиями (Manage Information Technology);

• управление финансовыми ресурсами (Manage Financial Resources);

• приобретение, строительство и управление собственностью (Acquire, Construct, and Manage Property);

• управление охраной окружающей среды (Manage Environmental Health and Safety (EHS));

• управление внешними связями (Manage External Relationships);

• управление знаниями, улучшениями и изменениями (Manage Knowledge, Improvement, and Change).

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

Основные процессы – это процессы ЖЦ продукции компании. Это «горизонтальные» процессы, направленные на создание и реализацию товара или услуги, представляющих ценность для клиента и обеспечивающие доход компании.

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

1) первичное взаимодействие с клиентом и определение его потребностей;

2) реализация запроса (заявки, заказа, контракта и т.п.) клиента;

3) послепродажное сопровождение;

4) мониторинг удовлетворения потребностей. Процесс «реализация (запроса клиента)» может быть декомпозирован на следующие подпроцессы (процессы более низкого уровня):

• разработка (проектирование) продукции;

• закупка (товаров, материалов, комплектующих изделий), в том числе: o транспортировка (закупленного); o разгрузка, приемка на склад и хранение (закупленного);

• производство (со своим технологическим циклом и внутренней логистикой);

• приемка на склад и хранение (готовой продукции);

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

• пуско-наладка;

• оказание услуг (предусмотренных контрактом на поставку или имеющих самостоятельное значение) и т.п.

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

• стратегическое управление;

• организационное проектирование (структуризация);

• маркетинг;

• финансово-экономическое управление;

• логистика и организация процессов;

• менеджмент качества;

• управление персоналом. При процессном описании управленческую деятельность можно «развертывать» по так называемому «управленческому циклу» (принятия решения), который включает следующие процессы:

1) сбор и анализ информации (проверка на достоверность);

2) подготовка альтернатив;

3) выбор альтернативы (принятие решения);

4) организация реализации решения;

5) контроль исполнения;

6) анализ;

7) коррекция (регулирование).

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

1) определение состава задач (обособленных функций, операций);

2) выбор исполнителей (распределение зон и степени ответственности);

3) проектирование процедур (последовательности и порядка исполнения);

4) согласование и утверждение регламента исполнения (- процесса, плана мероприятий);

5) отчетность об исполнении;

6) контроль исполнения (процедурный контроль);

7) анализ причин отклонений и регулирование (возврат к 1, 2 или 3).

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

Построение дерева БП

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

Таким образом, работы, перечисленные на этапе текстового описания, «распределяются» по «веткам» классификационного дерева.

Примеры БП управления (второй уровень дерева на ветке «БП управления»): планирование бюджета; составление штатного расписания; планирование закупок; планирование продаж и т.д. Для крупных предприятий БП можно объединять в подкатегории и подгруппы. Например, для БП управления это могут быть следующие категории: управление закупками и запасами; управление производством; управление продажами; управление финансами и т.д. Следующим шагом при проектировании ИС является выбор объекта автоматизации – группы процессов, которые будут осуществляться при помощи средств вычислительной техники. Это могут быть все основные процессы (для разработки автоматизированной системы учета основной деятельности), часть основных, например, для автоматизации продаж, для автоматизации производства, могут включать процессы управления или часть процессов управления при проектировании АСУ. В результате происходит «сужение» предметной области, и процессы, оставшиеся за ее пределами, попадают в область «внешней среды». В IDEF0 инструментом построения иерархии процессов является «дерево узлов» (Node Tree) (рис. 2.3.).

2. СТРУКТУРНЫЙ АНАЛИЗ И СТРУКТУРНОЕ ПРОЕКТИРОВАНИЕ

2.1. Основные понятия структурного анализа и структурного проектирования

Структурным анализом принято называть метод исследования системы, которое начинается с ее общего обзора и затем детализируется, приобретая иерархическую структуру с все большим числом уровней. Решение трудных проблем путем их разбиения на множество меньших независимых задач (так называемых «черных ящиков») и организация этих задач в древовидные иерархические структуры значительно повышают понимание сложных систем. В инженерии ПО (software engineering), Структурный анализ (Structured Analysis, SA) и одноименное с ним Структурное проектирование (Structured Design, SD) – это методы для анализа и преобразования бизнес-требований в спецификации и, в конечном счете, в компьютерные программы, конфигурации аппаратного обеспечения и связанные с ними ручные процедуры. Структурный анализ, СА (Structured Analysis, SA) и Структурное проектирование, СП (Structured Design, SD) являются фундаментальными инструментами системного анализа и развивались из классического системного анализа 1960-70-х годов (см. гл. 1.1). Структурный подход заключается в поэтапной декомпозиции системы при сохранении целостного о ней представления Основные принципы структурного подхода (первые два являются основными): 1) принцип «разделяй и властвуй» – принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;

2) принцип иерархического упорядочивания – принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

3) принцип абстрагирования – заключается в выделении существенных аспектов системы и отвлечения от несущественных;

4) принцип формализации – заключается в необходимости строгого методического подхода к решению проблемы;

5) принцип непротиворечивости – заключается в обоснованности и согласованности элементов.

2.2. Метод структурного анализа и проектирования SADT

SADT (Structured Analysis and Design Technique) – это методология инженерии разработки ПО (software engineering) для описания систем в виде иерархии функций (функциональной структуры).

Основы SADT

SADT использует два типа диаграмм:

1) модели деятельности (activity models);

2) модели данных (data models).

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

• главный блок (box), где определено названиее процесса или действия;

• с левой стороны блока – входящие стрелки: входы действия;

• сверху – входящие стрелки: данные, необходимые для действия;

• внизу – входящие стрелки: средства, используемые для действия;

• справа – исходящие стрелки: выход действия.

SADT использует декомпозицию на основе подхода «сверху вниз». Каждый уровень декомпозиции содержит до 6 блоков.

SADT начинается с уровня (level) 0, затем может быть детализирован на более низкие уровни (1, 2, 3, ...). Например, на уровне 1, блок уровня 0 будет детализирован на несколько элементарных блоков и так далее …

На уровне 1 действие «Manufacture computers», может быть разбито (declined), например на 4 блока:

1) получить электронные компоненты («receive electronic components»);

2) сохранить электронные компоненты («store electronic components»);

3) доставить электронные компоненты на сборочную линию («bring electronic components to the assembly line»);

4) собрать компьютеры («Assemble computers»).

Семантика стрелок для действий (activities):

• входы (Inputs) входят слева и представляют данные или предметы потребления (consumables), нужные действию (that are needed by the activity); • выходы (Outputs) выходят справа и представляют данные или продукты, производимые действием (activity);

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