Технико-экономическая характеристика предметной области

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

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

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

Рисунок 2.1 – Архитектура предприятия

 

Корпоративная миссия подразумевает формулировку основной цели функционирования предприятия.

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

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

Описание системы документооборота позволит оценить информационные потоки, курсирующие в организации.

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

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

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

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

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

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

- провести декомпозицию решения задачи;

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

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

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

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

- наличие выплат штрафных санкций и неустоек;

- простои оборудования;

- низкая производительность труда в производственной сфере;

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

- высокая трудоемкость обработки информации (привести объемно-временные параметры);

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

- невысокая достоверность результатов решения задачи из-за дублирования потоков информации;

- несовершенство организации сбора и регистрации исходной информации;

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

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

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

Ниже приводится содержание основных компонент документа «Постановка задачи».

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

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

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

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

Пример. Назначением реализации работы «……» может служить:

1. автоматизация получения по электронной почте входных документов;

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

3. ведение файлов с условно-постоянной информацией в базе данных;

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

4. выдача справочной информации:

а) по регламентированным запросам;

б) по нерегламентированным запросам.

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

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

- источники поступления оперативной и условно-постоянной информацией и периодичность ее поступления;

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

- порядок ввода первичной информации (названия документов) и перечень используемых экранных форм;

- краткая характеристика результатов (названия результатных документов, экранных форм выдачи результатов, перечень результатных файлов, способов их выдачи: на экран, печать или в канал связи) и мест их использования;

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

- режим решения задачи (пакетный, диалоговый, с использованием методов телеобработки или смешанный);

- периодичность решения задачи.

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

Обзор рынка программных средств удобно проводить с помощью Internet. Адреса используемых при обзоре ресурсов следует добавить в список литературы ВКР.

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

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

Раздел 2. Проектная часть

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

2.1. Моделирование бизнес-процесса(ов), задачи (комплекса задач)

2.1.1. Функциональная модель и ее описание (IDEF0).

2.1.2 Построение диаграммы действий (UML) в рамках автоматизируемого процесса

2.1.3. Имитационное моделирование бизнес-процесса (если необходимо)

2.2. Информационное обеспечение задачи (комплекса задач, АРМ)

2.2.1. Информационная модель и ее описание (Диаграммы потоков данных DFD, «сущность-связь» ERD, структуры БД IDEF1X)

2.2.2. Используемые классификаторы и системы кодирования

2.2.3. Характеристика нормативно-справочной информации

2.2.4. Входной оперативной информации

2.2.5. Характеристика результатной информации

2.3. Формирование окончательных требований на автоматизацию (комплекса задач)

2.4 Описание проектной реализации проблемы (описание внедряемого программного продукта)

Детализация параграфов раздела

2.1. Моделирование бизнес-процесса(ов), задачи (комплекса задач).

2.1.1. Функциональная модель и ее описание (IDEF0). Модель бизнес-процессов согласно методологии SADT создается на основе принципа декомпозиции: «…декомпозиция заключается в начальном разделении объекта на более мелкие части и последующем соединении их в более детальное описание объекта.» На верхнем уровне модели рассматриваемая система представляется виде одного процесса, например, «Деятельность по производству и продаже оборудования», далее он декомпозируется на совокупность бизнес-процессов верхнего уровня. Каждый из бизнес-процессов верхнего уровня декомпозируется на ряд подпроцессов. В качестве критерия выделения подпроцессов второго уровня можно использовать промежуточные состояния объекта управления. Например, процесс «Продвижение и продажи» может быть декомпозирован на подпроцессы:

1. Продвижение продуктов.

2. Выяснение потребности клиента.

3. Заключение договора с потребителем.

4. Прием текущих заказов.

5. Производственное планирование.

6. Организация выполнения заказа клиента.

7. Организация удовлетворения претензий клиентов.

8. Анализ удовлетворенности клиентов.

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

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

Уровень модели	Используемая нотация	Комментарий
	IDEF0 (контекстная диаграмма)	Модель, выполненная в нотации IDEF0 имеет контекстную диаграмму верхнего уровня А-0, на которой объект моделирования представлен единственным блоком с граничными стрелками. Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Диаграмма A-0 устанавливает область моделирования и ее границу.
	IDEF0	1 уровень содержит процессы верхнего уровня модели.
	IDEF0	2 уровень содержит декомпозицию процессов верхнего уровня. Например, процесс второго уровня «Продвижение продуктов» может быть декомпозирован на подпроцессы 3 уровня: 1. Группировка клиентов и анализ клиентской базы 2. Разработка программы удержания клиентов 3. Определение потребности по привлечению новых клиентов 4. Разработка комплекса продвижения продуктов на целевые рынки 5. Проведение мероприятий комплекса продвижения

 

2.1.2 Построение диаграммы действий (UML) в рамках автоматизируемого процесса. После построения функциональной модели бизнес-процесса необходимо провести его детальное моделирование.

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

Детальная модель бизнес-процесса должна включать:

- набор прецедентов, отражающих возможные варианты выполнения бизнес-процессов;

- диаграммы действий, детально описывающие последовательность выполнения бизнес-процессов.

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

 

2.1.3. Имитационное моделирование бизнес-процесса (если необходимо). Хотя потоковые диаграммы и таблицы адекватно отвечают на вопрос «что», они не могут ответить на вопросы «как», «когда» и «где». Бизнес-процессы слишком сложны и динамичны. Их невозможно понять и проанализировать, используя одни лишь потоковые диаграммы и электронные таблицы.

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

Процесс моделирования - это методика, позволяющая представлять в рамках динамической компьютерной модели действия людей и применение технологий, используемых в изучаемых процессах реинжиниринга. Проведении моделирования предполагает осуществление четырех основных этапов: 1) построение модели, 2) запуск модели, 3) анализ полученных показателей эффективности, 4) оценка альтернативных сценариев.

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

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

- повышение уровня обслуживания;

- сокращение общей длительности цикла процесса;

- повышение производительности;

- сокращение времени ожидания;

- снижение затрат на осуществление данной деятельности;

- снижение затрат на хранение товарно-материальных запасов.