Совершенствование процесса разработки средств автоматизации управления на ЗАО "Авиастар-СП"

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

6. Методология моделирования потоков данных DFD (Data Flow Diagrams);

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

Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям - потребителям информации. Таким образом, основными компонентами диаграмм потоков данных являются:

-внешние сущности;

-системы/подсистемы;

-процессы;

-накопители данных;

-потоки данных.

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

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

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

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

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

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

D1	<Имя накопителя>

Рис.2 Накопитель данных

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

Рис.3 Поток данных

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

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

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

7. Методология моделирования данных ERD (Entity-Relationship Diagrams).

Цель методологии состоит в построении концептуальной схемы данных в форме одной модели или нескольких локальных моделей. Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи).

Первым шагом моделирования является определение сущностей системы.

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

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

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

-сущность обладает одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь;

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

-каждая сущность может обладать любым количеством связей с другими сущностями модели.

Следующим шагом моделирования является идентификация связей.

Связь (Relationship) - поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области, при которой, как правило, каждый экземпляр одной сущности, называемой родительской сущностью, ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, называемой сущностью-потомком, а каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущности-родителя. Таким образом, экземпляр сущности-потомка может существовать только при существовании сущности родителя.

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

Степень связи и обязательность графически в данной методологии изображаются следующим образом (рисунок 4).

Рис.4 Графическое изображение степени связи и обязательности.

Последним шагом моделирования является идентификация атрибутов.

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

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

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

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

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

Помимо перечисленных основных конструкций модель данных может содержать ряд дополнительных:

Подтипы и супертипы: одна сущность является обобщающим понятием для группы подобных сущностей.

Взаимно исключающие связи: каждый экземпляр сущности участвует только в одной связи из группы взаимно исключающих связей.

Рекурсивная связь: сущность может быть связана сама с собой.

Неперемещаемые (non-transferrable) связи: экземпляр сущности не может быть перенесен из одного экземпляра связи в другой.

Анализируя все вышеизложенные методики описания или документирования, составим общую таблицу (таблица1), в которой покажем, какая методика может представлять какой фактор.

При этом будут использоваться следующие обозначения:

- х - фактор представлен подробно;

(х) - фактор представляется в общих чертах;

ячейка пустая - фактор совсем отсутствует.

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

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

Соотношение методологии моделирования с описываемыми факторами Таблица 1

Фактор	Характер процедур	Время	Документы	Информация	Географическое месторасположение	Местоположение организации	Отделы, сотрудники	Периодичность	Методика
№ п/п	Методика описания
1.	Методология составления схемы иерархического обзора	(х)
2.	Методология моделирования детальной схемы процесса	х	(х)	х	(х)	(х)	(х)	(х)	(х)	(х)
3.	методология моделирования схемы управления формами	х		х			х	х
4.	методология моделирования схемы движения форм	(х)		х			(х)	х
5.	методология функционального моделирования процесса	х		х	х	(х)	(х)	х		х
6.	методология моделирования потоков данных	х		(х)	х	(х)	(х)	(х)		(х)
7.	методология моделирования данных	х		(х)	(х)		(х)	х	(х)

Выделим следующие цели анализа процессов разработки программных САУ:

1. Эффективность управления процессом;

2. Длительность цикла процесса, ограниченного по времени его выполнения (эффективность процесса);

3. Результативность и производительность маршрутизации процесса;

4. Анализ эффективности организации системы внутреннего контроля;

5. Продуктивность процесса;

6. Наличие дублирования (мероприятий или баз данных) и/или избыточных действий.

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

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

Некоторыми признаками дефектов процессов могут быть возникновение задержек при операциях по обработке данных (увеличение опозданий, срока выполнения процесса и т.д.), подготовка схожих отчётов, увеличение затрат на обработку данных без адекватного роста производства и другие.

Итак, подробно рассмотрим каждое направление анализа (цели анализа).

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

Важными для анализа вопросами являются:

-для всех ли существенных структурных единиц (отделов, секторов, функций и т.д.), субъектов (работников, поставщиков, потребителей и т.д.) и изделий (конечных продуктов, сырья и материалов, средств производства и т.д.) поставляется информация?

-являются ли поставляемые данные исчерпывающими и вполне достаточными?

-оптимальна ли периодичность и непрерывность, с которой поставляются данные?

-являются ли данные достаточно критическими (ценными) и возможно ли сравнение их со стандартом?

-достаточно ли имеется данных о различных фазах процесса?

-все ли возможные аспекты (информация о месторасположении, источниках, крайних сроках, мощности и т.д.) отражены в системе управления информацией?

-все ли данные достаточно надёжны?

-адекватна ли скорость обработки и предоставления данных?

Для разных процессов наиболее благоприятная ситуация управления, учитывая предыдущие вопросы, будет отличаться.

Для анализа эффективности управления в процессах разработки САУ выделяются процессы управления. Причём цикл каждого отдельного блока управления здесь должен быть представлен следующим образом. Первым шагом является определение требуемого результата, который может называться стандартом или нормой. Стандарт используется для сравнения с наблюдаемыми результатами. Определяется отклонение от стандарта и указывается настройка процесса. Указанная настройка может выразиться в изменении стандарта и/или корректировке мероприятий. Это модифицированное мероприятие наблюдается снова и сравнивается со стандартом. Указанная настройка может также привести к изменению стандартов на уровне подпроцессов или ресурсов [16, c. 97].

Большое влияние на эффективность управления процессом оказывает организационная структура управления.

Мильнер Б.З. дает следующее понятие организационной структуре: «Организационная структура, представляющая собой определённую упорядоченность задач, ролей, полномочий и ответственности, создает условия для осуществления предприятием своей деятельности и достижения установленных целей.» [16, c. 51]

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

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

Анализ своевременности выполнения и длительности цикла. Методики, учитывающие элемент времени, можно разделить на две группы:

-Методики, измеряющие своевременность выполнения процессов;

-Методики, анализирующие длительность цикла [17, c. 47].

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

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

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

Выполнение исследования случайной выборки должно проводиться с учётом приведённых ниже шагов:

1. Определить масштаб исследования случайной выборки.

2. Решить, какие части совокупности подлежат более детальному изучению.

3. Стандартизировать требуемую длительность цикла.

4. Провести исследования случайной выборки.

5. Определить количество рабочих дней, необходимых на каждое наблюдение.

6. Рассчитать среднюю продолжительность выполнения процесса, число раз превышения норм, среднее превышение.

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

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

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

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

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

-данные, содержащиеся в отсылаемых и получаемых внешних документах;

-данные, задающие начальные условия;

-данные, содержащиеся в путевых листах;

-данные записей, относящихся к реестрам.

Имеет смысл связывать точки измерений с прибытием (выбытием) документов в (из) отделов. В рамках отделов точки измерений следует связывать с выполнением или завершением основных мероприятий. Сумма средних по точкам измерений значений длительности цикла и связанное с ним время ожидания определяют общую длительность цикла процесса. Для каждого наблюдения должно быть рассчитано количество рабочих дней между точками последовательных измерений. Полное число рабочих дней между первой и последней точкой измерения представляет собой длительность цикла за период наблюдения. Среднее число дней между двумя точками измерений по всем наблюдениям представляет собой среднюю длительность цикла между этими точками измерений.

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

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

Результативность и производительность маршрутизации процесса.

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

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

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

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

При анализе маршрута движения документов следует рассмотреть производительность и затраты на применение и возможное привлечение альтернативных методов перемещения документов (пневматическая почта, компьютерные сети, телефонные почтовые системы и т.д.).

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

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

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

1. Сформулировать систему внутреннего контроля.

2. Оценить систему внутреннего контроля.

3. Оценить полную систему внутреннего контроля (для всех вместе взятых процессов).

4. Сформулировать основные принципы изменения процессов.

Чтобы сформулировать систему внутреннего контроля необходимо чётко и ясно описать и гарантировать следующие требования:

-используемые исходные материалы должны являться точными и полными;

-исходные материалы обрабатываются точно и тщательно;

-исходные материалы регистрируются в процессе и далее обрабатываются вовремя;

-в рамках, определённых для этой цели, принимаются решения и проводятся мероприятия, касающиеся процесса. Эти рамки определяются применяемыми ограничениями и правилами.

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

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

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

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

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

Формулирование основных принципов изменения процессов. На основе результатов этапов 2 и 3 определяется способ улучшения интеграции внутрифирменных средств контроля в анализируемом процессе.

Продуктивность процесса. Эффективность - это мера того, насколько эффективно используются ресурсы (люди, деньги, пространство, компьютерная память и т.д.). При изменении производительности предпринимается попытка сформировать суждение о пропорциональном соотношении между затратами и объёмом производства в различных процессах. Результатом анализа должно стать представление величины контрольных цифр или относительных показателей, которые дают представление о производительности изучаемого элемента.

Анализ проводится посредством осуществления следующих мероприятий:

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

2. Определить единицы измерения для каждого продукта. Этот этап определяет, каким образом измеряется производство. Для продуктов, приведённых в мероприятии 1, это может быть количество программистов работающих на персональных компьютерах, количество уведомлений, количество часов участия, количество персонала и т.д. Единицы измерения должны быть выбраны таким образом, чтобы они указывали на величину производства.

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

4. Определить затраты на продукты процесса. Затраты должны быть поставлены в соответствии мероприятиям, и затраты по мероприятиям и по продуктам должны быть просуммированы. Если затраты не могут быть рассчитаны напрямую, то следует использовать методики разбивки затрат.

5. Определить масштаб производства. Масштаб производства определяется в этом мероприятии делением количества обработанных единиц на общие затраты по продукту.

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

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

Анализ должен проводиться путём осуществления следующих этапов:

1. Мероприятия должны быть сгруппированы в соответствии с целями. Рекомендуется разрабатывать цель для каждого процесса или мероприятия.

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

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

4. Для каждой цели следует рассчитать и просуммировать затраты на различные мероприятия. Это делается путём отнесения на мероприятия затрат на оплату труда персонала и других расходов.

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

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

7. Исследовать, могут ли цели быть достигнуты другим, менее дорогостоящим способом. Иногда это можно сделать путём предъявления менее строгих требований к качеству информации. Эти требования могут относиться к степени детализации информации, периодичности, временным границам, в рамках которых возникает информация, уровень точности и т.д.

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

Перед проведением комплексного анализа процесса необходимо заранее сделать выбор среди различных целей и установить приоритеты.

Цели анализа можно подразделить в соответствии с проблемами анализа. Предметом анализа являются:

-условия, в которых протекает процесс (цели анализа 3,4,5);

-фактическое выполнение мероприятий (цели анализа 2,5,6,7);

-конечный продукт процесса (цели анализа 1,2,5).

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

1. Во-первых, определить конечный продукт и эффективность управления потоками. Если всё это в порядке, определить, стоит ли их изучать.

2. Если да, то определить, выполняются ли условия эффективного функционирования.

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

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

-анализ существующих процессов разработки уже был проведён;

-рассматривается вопрос о построении новых или улучшенных процессов разработки.

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

При проектировании процессов разработки САУ целесообразно использовать нисходящий подход: от общего к частному, при котором сначала производится грубое, приближенное проектирование, а затем оно детализируется, на каждой фазе идёт возвращение к точным принципам и целям.

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

Сначала проведём исследование метода проектирования нового процесса разработки программных САУ, а затем метода проектирования изменений, направленных на улучшение процесса.

Подход к проектированию новых процессов состоит из четырёх шагов:

1. Определение начальной позиции системы (службы, подразделения), в которой реализуется процесс;

2. Определение применения информации;

3. Проектирование логической структуры;

4. Проектирование физической структуры.

Рассмотрим отдельно каждый шаг.

Определение начальной позиции системы.

При определении начальной позиции системы необходимо сформулировать:

-первичные процессы;

-метод управления контроля;

-организационную структуру.

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

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

Как только требования к первичным процессам определены, очень важно установить, как надо управлять этими процессами. Естественно, что управление будет направлено на то, чтобы удовлетворить требованиям потребителей САУ, требованиям закона и внутренним целям.

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

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

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

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

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

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

2. критерии качества этой информации;

3. подходящий набор средств информационного управления.

Раскроем содержание каждого момента.

1. Выявление требуемой информации может производиться путём осуществления следующих мероприятий:

-выявить ключевые факторы успеха;

-определить основные процессы разработки;

-выявить взаимосвязи между ключевыми факторами успеха и процессами.

-определить или ввести в действие контрольные переменные;

-определить форму и периодичность отчётности по управлению.

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

В ходе первого мероприятия выделяются ключевые факторы успеха, которые могут быть получены на основе стратегий и целей системы (организации, подразделения), реализующей проектируемый процесс. В ходе второго мероприятия выделяются процессы. С помощью функциональной схемы организации, в существующий список процессов вводится иерархия. Эта иерархия помогает понять структуру и состав всех процессов системы.

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

В четвёртом мероприятии устанавливаются или вводятся в действие контрольные переменные.

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

В пятом мероприятии описываются форма и периодичность отчётности по управлению. Эти отчёты состоят из оценок контрольных переменных в отношении стандарта, плана и/или прогноза. Финансовые отчёты используются для того, чтобы показать, согласуются ли процессы с утверждённым планом.

2. Критерии качества необходимой информации. Что касается требований к информации, следует установить требования к её качеству в плане актуальности, надёжности, формы представления и эффективности.

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

3. Цели и средства информационного управления. Основные меры информационного управления (также называемого внутренним контролем) направлены на надёжность сбора, документирования и обработки данных. Целью этих мер является обеспечение требуемой степени надёжности информационного управления.

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

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

1. Концептуальная модель данных;

2. Иерархический обзор процессов;

3. Дополнительный, более подробный анализ связей между моделью данных и процессами.

Рассмотрим каждый элемент.

1. Концептуальная модель данных. В течение этой процедуры должны быть установлены свойства мероприятий, для которых нужны данные, и отношения между этими мероприятиями. Строится концептуальная модель данных. Порядок построения описан выше на этапе документирования процесса.

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

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

Таким образом, процесс охватывает ввод базовых данных и получение на выходе обработанных данных. Методика, применяемая к этому процессу, состоит в построении схемы информационных потоков (она была описана выше), при помощи которой анализируются методы создания выходных данных из базовых данных, введённых ранее.

С помощью этого метода можно выделять мероприятия системы в соответствии с моделью данных.

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

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

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

Проектирование физической структуры. Проектирование физической структуры процессов разработки включает следующие вопросы:

1. Какие организационные единицы должны осуществлять мероприятия проектируемого процесса;

2. Какие мероприятия должны быть включены как часть процесса и какова должна быть последовательность действий в проектируемом процессе;

3. Какие файлы и формы данных являются необходимыми.

4. Подробное описание процесса.

5. Затраты и длительность цикла проектируемого процесса.

Рассмотрим каждое мероприятие.

1. Распределение мероприятий по организационным единицам. Когда иерархический обзор объединяется со схемой организационной структуры, образуется полный обзор организационных единиц. С помощью этой матрицы можно определить степень причастности конкретной организационной единицы к конкретному процессу.

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

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

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

3. Определение необходимых файлов данных и форм. Если определена последовательность мероприятий в процессе, то документы, необходимые для обмена данными между различными мероприятиями, можно определить из таблицы, где по горизонтали представлена последовательность мероприятий, а по вертикали располагается два столбца: «входные документы» и «выходные документы». Данные, созданные в первом мероприятии, отмечаются в столбце «выходные документы». Кроме того, там, где применима информация из документа, это отмечается в столбце «входные документы».

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

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

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

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

-Составление других видов документирования, схем инструкций и т.д.

5. Вычисление затрат и длительности цикла. Оценка времени делается для каждого из заданных мероприятий во время проектирования новых процессов. Кроме того, указывается категория служащих (или сотрудников), выполняющих мероприятие. После этого для каждой категории служащих (или для отдельного сотрудника) рассчитываются затраты в единицу времени. Перемножая время, затраченное на мероприятие, на затраты в единицу времени, получим затраты на мероприятие. Сложив все затраты, получим общую стоимость процесса в целом. Естественно, что эти затраты должны возрастать с добавлением затрат на инструменты, материалы, накладные расходы и т.д.

Далее рассмотрим проектирование изменений, направленных на улучшение существующего процесса [7, c. 297].

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