Проектирование информационных систем

Содержание:

Введение

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

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

Целью курсовой работы является рассмотрение основ проектирования реализации операций бизнес-процесса «Продажи»

Для достижения данной цели были поставлены следующие задачи:

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

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

- запроектировать операции бизнес-процесса «Продажи»

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

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

Глава 1 Аналитическая часть. Разработка, моделирование, оптимизация бизнес-процессов

Современные методы управления компанией все чаще заимствуют иностранные методики и технологии. И не потому, что это модно, а потому, что это удобно и эффективно. Одна из таких методик разбивает всю рутинную работу на элементарные составляющие и затем подробно описывает каждый полученный бизнес-процесс. Это занимает довольно много времени, но выведенная схема позволяет находить и слабые места, и чрезмерно раздутые функциональные обязанности, и нечетко поставленные задачи. Единожды потратив время, менеджмент может передать часть своей ответственности вниз по иерархической лестнице, освободив себе время для стратегического планирования^[1].

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

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

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

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

- это сделано в нужный момент;

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

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

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

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

•понять общую структуру организации деятельности и определить динамику ее развития;

•выявить текущие проблемы и возможности их преодоления;

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

•сформулировать требования к необходимому программному обеспечению.

Конечно, само по себе описание бизнес-процессов не представляет никакого интереса. Но вот для реинжиниринга это - первостепенная задача. Только поняв структуру, взаимосвязи и пути движения информационных потоков, можно говорить о переосмыслении смысловой нагрузки как самого предприятия, так и его отдельных подразделений^[2]. Но и реорганизация должна проводиться ради достижения какой-то цели: улучшения качества обслуживания клиентов; сокращения затрат; предоставления больших свобод в принятии решений исполнителям (уменьшения сроков выполнения работ) и т. д.

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

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

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

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

•управляющие – те, что ставят цели и задачи подразделениям и конкретным исполнителям;

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

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

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

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

- Граница – это начало и конец выполнения простой операции.

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

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

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

- Исполнитель – персонал компании, занятый в одном процессе.

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

- Контроль качества – отраслевые или внутренние (принятые руководством компании) показатели, позволяющие определить эффективность работы.

1.2 Обязательное выделение элементарных процессов

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

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

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

•Сертификация организации по международным стандартам (ISO). Создается единая для всех сотрудников система управления качеством.

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

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

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

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

1.3 Моделирование бизнес-процессов

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

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

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

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

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

•Что? Описывает, что конкретно делается в данной операции.

•Зачем? Передает цель выполнения операции.

•Когда? Определяет, кто инициирует выполнение.

•Кто? Называет конкретных исполнителей.

•Как? Перечисляет необходимые ресурсы.

Разработка бизнес-процессов предполагает, что можно использовать все способы описания. Таким образом, получится максимально подробная схема выполнения работ. Графический вариант выявит взаимосвязи функциональных подразделений, а табличный и текстовый передадут содержание каждой операции. К сожалению, автоматизация бизнес-процессов невозможна без этой трудоемкой предварительной работы^[4].

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

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

И все же, если основная задача предприятия - автоматизация бизнес-процессов, а привлекать внешние консалтинговые компании руководство не намерено, обязательно возникает вопрос: "С чего начать?" Первым делом создается рабочая группа из сотрудников компании. Желательно, чтобы члены рабочей группы обладали отличными аналитическими способностями и умением слушать. Ведь, как уже отмечалось, большая часть работы заключается в проведении личных интервью с исполнителями бизнес-процессов.

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

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

Любое описание можно разделить на такие составляющие:

•унифицированная форма процесса (чаще всего таблица);

•карта бизнес-процесса (может быть представлена в любой форме – текстовое описание, графический объект или таблица);

•маршруты (входящие и исходящие потоки информации, ресурсов и финансов);

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

•блок-схема (алгоритм выполнения бизнес-процесса);

•развернутое текстовое описание;

•документирование (создание документов, подтверждающих выполнение процесса);

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

•регламент (проще говоря, должностная инструкция).

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

1.4 Показатели бизнес-процессов

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

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

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

В основе большинства методологий моделирования сейчас положены принципы структурного анализа и проектирования (SADT - Structured Analysis and Design Technique), а также некоторые алгоритмические языки. Можно говорить о существовании нескольких основных моделей анализа бизнес-процессов:

- Business Process Modeling – собственно, моделирование – раскрывает функциональную сторону существования фирмы.

- Work Flow Modeling – описывает потоки работ и похож на составление блок-схем.

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

Цикл Шухарт-Деминга

Крупные бизнес-процессы (1С позволяет выделить их из общего списка) рекомендуют описывать в отдельном документе, который называется «Регламент производства работ». Все, что носит менее значимый характер или состоит из небольшого количества простых операций, принято описывать в должностных инструкциях^[5].

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

При составлении регламента следует учесть принципы, которые обеспечивают соответствие модели Шухарта-Деминга:

1.Расчет плановых показателей на будущий период.

2.Анализ динамики отклонений и документирование предположительных причин.

3.Определение корректирующих операций и анализ их эффективности.

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

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

Ведь именно налаженная и тщательно проработанная система позволит не только упростить получение предприятием сертификатов соответствия международным стандартам качества ISO 9001:2008, но и значительно повысить эффективность работы каждого сотрудника.

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

Глава 2 Проектная часть

2.1. Примеры бизнес-процессов

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

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

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

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

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

Остановимся подробнее на заданной теме курсовой работы. Для проектирования операций бизнес-процесса «Продажи» выполним следующие действия:

В целом можно выделить следующие цели и задачи отдела продаж:

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

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

Поиск заказчиков.

1. Систематический поиск новых клиентов.
2. Работа с постоянными заказчиками.
3. Продажа основной и сопутствующей продукции.
4. Ведение необходимой документации.
5. Сопровождение сделок.

6. Обработка входящих запросов и информационное сопровождение.

7.Создание отдела продаж должно основываться на вышеперечисленных задачах, целях и функциях.

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

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

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

По сути управление отделом продаж - это управление бизнес-процессами и этапами.

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

Бизнес-процессы отдела продаж делятся на основные и вспомогательные.

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

- процесс продажи;

- процесс сопровождения.

Вспомогательные бизнес-процессы отдела продаж поддерживает выполнение основных процессов.

2.2 Проектирование реализации операций бизнес-процесса «Продажа»

Для того чтобы документировать механизмы передачи и обработки информации в моделируемой системе, используются диаграммы потоков данных (Data Flow Diagrams). Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота организации. Чаще всего диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0.

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

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

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

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

•Вход. Так обозначают материал или информацию, которые станут результатом на выходе.

•Управление. Нормативные, регламентирующие и управляющие данные, которыми руководствуется процесс во время своего исполнения.

•Выход. Информация или материал, которые являются результатом работы, которые дают возможность «теоретически» осмотреть, что показывает IDEF0 диаграмма. Примеры реализации различных систем в такой модели можно найти в открытом доступе.

•Механизм. Ресурсы, необходимые для выполнения работы.

•Вызов. Часть работы, которая выполняется за рамками процесса

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

Методология IDEF0 предоставляет целый ряд правил и рекомендаций по своему использованию и улучшению качества использования. Так, в диаграмме отображается один блок, на котором можно задать название системы, её назначение. К блоку или от блока ведёт 2-5 стрелок. Можно больше или меньше, но как минимум две стрелки необходимы для входа/выхода, а остальные для дополнительных работ и их указания на диаграмме. Если стрелок больше 5, следует задуматься об оптимальности построения модели, и нельзя ли сделать её ещё более детализированной^[8].

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

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

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

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

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

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

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

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

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

Вы уже узнали, что такое IDEF0 диаграмма, примеры и правила построения таких диаграмм частично увидели. Теперь следует обратиться и к практике. Для лучшего понимания объяснение будет идти не на какой-то «общей» модели, а на конкретном примере, который позволит лучше и полнее понять особенности работы с IDEF0 в программе BPWin.

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

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

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

Продажа

Продавец

Товар

Также изобразим графически проектирование информационных систем «Продажа»

1.В графе 1 укажем номер операции и краткое наименование диаграммы действий проектируемого бизнес-процесса. Данные в графу необходимо ввести в соответствии с таблицей описаний операций.

2. В графу 2 перенесем операции из таблицы описания операций.

3. В графе 3 перечим необходимые разработки для реализации операций.

4. В графе 4 сформулируем специфику настройки функционала системы.

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

Таблица 1. - Пример проектирования операций бизнес-процесса «Продажи»

Номер операции на диаграмме	Номер операции на диаграмме	Номер операции на диаграмме	Номер операции на диаграмме	Номер операции на диаграмме
Продажи 1	Получение от клиента заказа с указанной номенклатурной единицей	Разработать шаблон импорта заявки клиента. Разработать функционал импорта заявки клиента в заказы	Шаблон может быть разработан на основе MS Excel, MS Word	Логистика, расчеты с клиентами
Продажи 2	Проверка наличия у клиента лицензии на заказанные товары	Разработать функционал, позволяющий при импорте заявки клиента в систему проверять наличие у клиента лицензии	Каждому клиенту ставится в соответствие лицензия. В лицензии указывается срок ее действия	Логистика
Продажи 3	Проверка наличия товарных запасов на складе для полного или частичного выполнения заказа	Разработать функционал, проверяющий наличие товарных запасов при импорте заявки клиента	При импорте заявки система проверяет наличие товара на складе	Логистика, сводное планирование
Продажи 4	Размещение заказа в реестре «неудовлетворенный спрос»	Разработать функционал, который при импорте заказа клиента и отсутствии товара на складе формирует заказ с меткой «отложен»	При импорте заявки, в случае отсутствия товара на складе, система формирует заказ со специальной меткой и размещает его в специальном реестре	Логистика
Продажи 5	Процесс формирования заявки на основании заказа в соответствии с договором клиента	Разработать механизм копирования в заявку строк из заказа и договора	Шаблон файла импорта должен содержать номер договора, но которому формируется заявка	Логистика
Продажи 6	Резервирование товара	Разработать функционал, позволяющий резервировать заказанный товар	Резервирование товара может происходить в системе двумя способами: автоматически и вручную	Логистика
Продажи 7	Проверка кредитного лимита и дебиторской задолженности	Разработать алгоритм проверки условий	При импорте заявки клиента система проверяет кредитный лимит клиента. В случае превышения кредитного лимита система выдает сообщение о превышении кредитного лимита и блокирует дальнейшую обработку	Торговля
Продажи 8	Подбор номенклатурных единиц	Автоматизации не подлежит		Функцио-нальность не требуется
Продажи 9	Формирование упаковочных листов	Разработать функциональность адресного хранения товара на складе		Логистика, управление складом
Продажи 10	Формирование счета, расходной накладной, счета- фактуры	Разработать электронную и печатную форму документов		Торговля
Продажи 11	Отгрузка, списание товара	Разработать взаимосвязь с финансовым блоком	Формирование проводки по выбытию товара со склада	Логистика, торговля

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

Заключение

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

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

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

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

4. Обеспечить надежный учет и контроль поступлений и расходования денежных средств на всех уровнях управления.

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

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

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

Библиография

Нормативно-правовые документы

1. Конституция Российской Федерации от 12 декабря 1993 г. (с изм. и доп., вступ. в силу с 21.07.2014)

Произведения из многотомного издания

1. Бобошко Д.Д. 1С: Предприятие версии 7.7: Программирование в примерах. М.: КУДИЦ-Образ, 2016. 235 с.

2. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: учебник. М.: Финансы и статистика, 2014. 353 с.

1. Грекул В.В. Проектное управление в сфере информационных технологий. М.: БИНОМ, ИНФРА-М, 2013.

2. Каляное Г.Н. CASE-технологии: Консалтинг в автоматизации бизнес-процессов. Изд. 3-е. М.: Горячая линия -Телеком, 2013.

3. Маклаков С.В. BPwin и ERwin. Case - средства разработки информационных систем. М.: Диалог-Мифи, 2016. 256 c.

4. Михайлов А.В. 1С:Предприятие 7.7/8.0: системное программирование. СПб.: БХВ-Петербург, 2015. 336 с.

5. Муромцев В.В. Проектирование информационных систем: Учебное пособие для студентов вузов заочной формы обучения по спец. 010502 "Прикладная информатика в экономике". Белгород: БелГУ, 2017. 160.

6. Постовалов С.Н., Постопавалова А.Ю. 1С: Предприятие 7.7. Уроки программирования. СПб.: БХВ-Петербург, 2018. 308 с.

7. Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем. Учебник:/ Под ред. Ю.Ф. Тельнова. М.: Финансы и статистика, 2016. 512 с.

8. СУБД Microsoft Access: Учебное пособие для вузов/Н.Н. Гринченко, Е.В. Гусев, Н.П. Макаров, А.Н. Пылькин, Н.И. Цуканова- М.: Горячая линия-Телеком, 2019.

1. Каляное Г.Н. CASE-технологии: Консалтинг в автоматизации бизнес-процессов. Изд. 3-е. М.: Горячая линия -Телеком, 2013. ↑

2. Вендров А.М. Проектирование программного обеспечения экономиче-ских информационных систем: учебник. М.: Финансы и статистика, 2014. 353 с ↑

3. Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование эконо-мических информационных систем. Учебник:/ Под ред. Ю.Ф. Тельнова. М.: Финансы и статистика, 2016. 512 с. ↑

4. Муромцев В.В. Проектирование информационных систем: Учебное по-собие для студентов вузов заочной формы обучения по спец. 010502 "При-кладная информатика в экономике". Белгород: БелГУ, 2017. 160. ↑

5. СУБД Microsoft Access: Учебное пособие для вузов/Н.Н. Гринченко, Е.В. Гусев, Н.П. Макаров, А.Н. Пылькин, Н.И. Цуканова- М.: Горячая линия-Телеком, 2019. ↑

6. Бобошко Д.Д. 1С: Предприятие версии 7.7: Программирование в при-мерах. М.: КУДИЦ-Образ, 2016. 235 с. ↑

7. Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование эконо-мических информационных систем. Учебник:/ Под ред. Ю.Ф. Тельнова. М.: Финансы и статистика, 2016. 512 с. ↑

8. Постовалов С.Н., Постопавалова А.Ю. 1С: Предприятие 7.7. Уроки программирования. СПб.: БХВ-Петербург, 2018. 308 с. ↑