Управление проектами в сфере информационных технологий. Лабораторная работа № Цель работы

Вид материалаЛабораторная работа

Содержание


Нормативные ссылки
Термины и определения
Методика описания бизнес-процесса
2. Руководители среднего звена
Форматы графических схем бизнес процессов
Графическое представление
Графическое представление
Тип стрелки
Графическое представление
Подобный материал:

Управление проектами в сфере информационных технологий.

Лабораторная работа № 1.


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


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

  1. НОРМАТИВНЫЕ ССЫЛКИ
  1. При разработке данного документа использованы следующие нормативные документы:
      1. ISO 9000:2000 Системы менеджмента качества - Основополагающие принципы и словарь.
      2. ISO 9001:2000 Системы менеджмента качества- Требования.
      3. ISO 19011:2002 Руководящие указания по аудиту систем менеджмента качества и/или систем экологического менеджмента.
      4. ГОСТ Р50.1.028-2001 Методология функционального моделирования IDEF/0.



  1. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ


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

деятельности (последовательность работ), которая по определенной технологии преобразует

входы в выходы, представляющие ценность для потребителя.

Владелец бизнес-процесса - должностное лицо, которое имеет в своем распоряжении

персонал, инфраструктуру, программное и аппаратное обеспечение, информацию о бизнес-

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

эффективность бизнес-процесса.

Вход бизнес-процесса - ресурс, обеспечиваемый внешним поставщиком.

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

Заказчик - должностное лицо, имеющее ресурсы и полномочия для принятия решения о

проведении работ по описанию бизнес-процесса.

Модель бизнес-процесса - графическое, табличное, текстовое, символьное описание бизнес-

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

Нотация - см. формат описания бизнес-процесса.

Поставщик - субъект, предоставляющий ресурсы.

Операция (работа) - часть бизнес-процесса, имеющая вход и выход.

Ресурсы - информация (документы, файлы), финансы, материалы, персонал, оборудование,

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

процесса и находящиеся в распоряжении владельца бизнес-процесса.

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

выполняемых структурным подразделением на постоянной основе.

Формат описания бизнес-процесса (нотация) - способ формирования графической

модели бизнес-процесса.

  1. Сокращения:

IDEF 0 - FIPS 183 США «Integration definition for function modeling (IDEF0)» .

«Интеграционное определение для моделирования функций»

IDEF 3 - (workflow modeling, Process Description Capture Method) методология описания

бизнес-процессов (потоков работ)

DFD - Data Flow diagramming, модель бизнес-процесса, составленная по принципу

отражения потоков данных.

  1. МЕТОДИКА ОПИСАНИЯ БИЗНЕС-ПРОЦЕССА
    1. Концепция описания бизнес-процессов Компании
  1. Не описанные и не регламентированные бизнес-процессы подлежат

рассмотрению, начиная с верхнего уровня. Далее, если это целесообразно, после

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

нижнего уровня.
  1. Понятие бизнес-процесса, операции и их иерархий поясняет рисунок 1.




Рисунок 1

  1. Отнесение деятельности к категории «бизнес-процесс» или «операция» зависит от

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

    1. Требования к описанию бизнес-процесса
  1. Бизнес-процесс подлежит описанию для достижения следующих целей, приведённых в таблице 1.






Цель описания бизнес-процесса

1. Руководители верхнего уровня

1.1.

Формирование эффективной системы управления на основе бизнес-процессов.

1.2.

Четкое разграничение ответственности и полномочий между руководителями

и подразделениями в рамках бизнес-процессов.

1.3.

Разработка показателей эффективности бизнес-процессов и методик их

оценки и анализа.

1.4.

Подготовка к созданию и внедрению Информационных Систем в Компании.

2. Руководители среднего звена

2.1.

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

2.2.

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

3. Специалисты

3.1.

Создание инструкций и методик, определяющих деятельность специалистов в

рамках бизнес-процессов.



Таблица 1

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

рисунке 2.

.

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

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



  1. ФОРМАТЫ ГРАФИЧЕСКИХ СХЕМ БИЗНЕС ПРОЦЕССОВ



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

соответствии с указанной на рисунке 1 последовательностью действий, представлен на

рисунках 5-10.
  1. Взаимосвязь различных нотаций описания Бизнес процессов показана на рисунку 3 (в DFD модели возможна декомпозиция процессов с целью более наглядного отображения модели).





Рисунок 3 Последовательность формирования моделей бизнес-процесса.

  1. Описание бизнес процессов в нотации DFD не входит в рамки данной работы.



  1. Правила формирования моделей бизнес-процессов в IDEF0



  1. Функциональная модель бизнес-процесса (IDEF0) представляет бизнес-процесс как совокупность выполняемых функций (направлений деятельности). Для определяемого в каждом конкретном случае уровня детализации модели, функции должны рассматриваться уже как операции, выполняемые в ходе бизнес-процесса.
  2. Модель IDEF0 рекомендована к применению при описании бизнес-процессов на верхнем уровне.
  3. При составлении функциональной модели бизнес-процесса (IDEF0) описываются выполняемые функции и входные, выходные потоки материальных, финансовых ресурсов и информации (документов, файлов).
  4. При описании бизнес-процесса одновременно могут применяться комбинации различных моделей . IDEF0, IDEF3 и DFD. Модель в IDEF0 можно декомпозировать на

модели IDEF3 и DFD при необходимости.
  1. Условные обозначения формата IDEF0 представлены в следующей таблице 2.






Наименование

Описание

Графическое представление

1

Процесс (функция или операция)

Объект служит для описания функций (операций, работ), выполняемых подразделениями/ сотрудниками предприятия.





2

Стрелка слева

Стрелка слева (вход) описывает входы функции (операции)



3

Стрелка слева

Стрелка слева (выход) описывает выходы функции (операции)



4

Стрелка сверху

Стрелка сверху (управление) описывает управляющее воздействие, например распоряжение, нормативный документ и т.д.



5

Стрелка снизу

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




Таблица 2

  1. На диаграмме IDEF0 стрелки связывают выполняемые функции.
  2. Стрелки-входы обозначают материальные, финансовые и информационные ресурсы, которые преобразуются функцией.
  3. Стрелки-выходы обозначают материальные, финансовые и информационные ресурсы, являющиеся результатом выполнения функции.
  4. Стрелки-управления обозначают правила, стандарты, указания, нормативы и т.д., в соответствии с которыми выполняется функция. Каждая функция должна иметь хотя бы одну стрелку-управление. Стрелки-управления рисуются только входящими в верхнюю грань блока, обозначающего функцию.
  5. Стрелки-механизмы обозначают средства выполнения функций: персонал, оборудование, станки, устройства, информационные системы и т.д.
  6. Стрелки изображаются вертикальными и горизонтальными отрезками прямых с наконечником на одном конце, пересекающиеся под прямым углом и сопряженные дугами.
  7. Стрелки соединяются с блоком следующим образом:
    1. концы стрелок должны касаться внешней стороны блока, но не пересекатьее;
    2. стрелки должны подсоединяться к блоку на его сторонах, присоединение в углах не допускается.
  8. При изображении стрелок допускаются их слияние и разветвление.
  9. Именование стрелок и создание меток в случае разветвления стрелок подчиняется следующим правилам:
    1. если стрелка именована до разветвления, а после разветвления ни одна из ветвей не именована, то подразумевается, что каждая ветвь моделирует те же данные или объекты, что и ветвь до разветвления;
    2. если стрелка именована до разветвления, а после разветвления какая-либо из ветвей не именована, то подразумевается, что она моделирует те же данные или объекты, что и до разветвления;
    3. недопустима ситуация, когда стрелка до разветвления не именована, а после не именована какая либо из ветвей.
  10. Правила именования сливающихся стрелок полностью аналогичны.
  11. В рамках одной диаграммы существует шесть типов отношений между блоками:
    1. доминирование;
    2. управление;
    3. выход - вход;
    4. обратная связь по управлению;
    5. обратная связь по входу;
    6. выход - механизм.
  12. Блоки, расположенные на диаграмме выше и левее, «доминируют» над блоками, расположенными ниже и правее.
  13. Отношение управления возникает тогда, когда выход одного блока служит управляющим воздействием на блок с меньшим доминированием.
  14. Отношение выход - вход возникает при соединении выхода одного блока с входом другого блока с меньшим доминированием.
  15. Обратная связь по управлению возникает тогда, когда выход некоторого блока создает управляющее воздействие на блок с большим доминированием.
  16. Отношение обратной связи по входу возникает тогда, когда выход блока становиться входом другого блока с большим доминированием.
  17. При построении модели бизнес-процесса в IDEF0 используется принцип декомпозиции. Декомпозиция функций производится для более подробного описания выбранной для декомпозиции функции. При декомпозиции функция раскладывается на множество функций, выполнение которых полностью обеспечивает реализацию декомпозированной функции.
  18. Диаграмма представляющая собой результат декомпозиции называется дочерней диаграммой, а декомпозируемая диаграмма - родительской диаграммой. Декомпозируемый блок, обозначающий функцию, называется родительским блоком.
  19. Функциональная модель IDEF0 представляется в виде совокупности иерархически упорядоченных диаграмм. Выполнение функции, отображенной на диаграмме верхнего уровня, детализируется на диаграммах нижнего уровня.
  20. Моделирование бизнес-процесса в IDEF0 начинается с построения контекстной диаграммы, которая представляет собой самое общее описание системы и ее взаимодействия с внешней средой. Контекстная диаграмма должна быть представлена с точки зрения цели моделирования.
  21. При формировании моделей в IDEF0 используются туннельные стрелки. Туннельные стрелки обозначаются как круглые скобки на конце или начале стрелок. Допускается использование квадратных скобок вместо круглых. Стрелка, помещенная в «туннель» там, где она присоединяется к блоку, означает, что данные выраженные этой стрелкой, не обязательны на следующем уровне декомпозиции. Стрелка, помещаемая в туннель на свободном конце означает, что выраженные ею данные отсутствуют на родительской диаграмме.
  22. Все граничные стрелки на дочерней диаграмме, за исключением стрелок помещенных в туннель, должны соответствовать стрелкам родительского блока.
  23. В составе диаграмм должна присутствовать контекстная диаграмма.
  24. Блоки на диаграмме должны располагаться по диагонали - от левого верхнего угла диаграммы до правого нижнего в порядке присвоенных номеров.
  25. Диаграммы (кроме контекстной) должны содержать не менее трех и не более восьми блоков.
  26. Каждый блок диаграммы получает номер, помещаемый в правом нижнем углу.
  27. Порядок нумерации - от верхнего левого к нижнему правому блоку (например, номера от 1 до 8).
  28. Каждый блок, не имеющей декомпозиции помечается небольшой диагональной чертой, расположенной в левом верхнем углу блока.
  29. Имена блоков (выполняемых функций) должны быть уникальными.
  30. Следует обеспечить максимальное расстояние между блоками и поворотами стрелок, а также между блоками и пересечениями стрелок для облегчения чтения диаграммы.
  31. Блоки всегда должны иметь хотя бы одну управляющую и одну выходную стрелку, но могут не иметь входных стрелок.
  32. Если одни и те же данные служат и для управления, и для входа, показывается только стрелка управления.
  33. Стрелки сливаются, если они представляют сходные данные и их источник не указан на диаграмме.
  34. Обратные связи по управлению рисуются «верхней петлей» (вверх и назад через верх).
  35. Обратные связи по входу изображаются «нижней петлей» (вниз и назад через низ).
  36. Стрелки объединяются, если они имеют общий источник или приемник, или они представляют связанные данные.
  37. При соединении большого числа блоков необходимо избегать необязательных пересечений стрелок. Следует минимизировать число петель и поворотов каждой стрелки.
  38. При описании функций, преобразующих информационные потоки, на диаграммах нижних уровней названиям стрелок-входов должен быть поставлен в соответствие конкретный документ или перечень документов.
  39. Построение стрелок-выходов подчиняется тем же правилам, что и стрелок-входов.
  40. Все стрелки-механизмы на диаграммах нижнего уровня должны иметь в своём названии точное название отдела или роли, выполняющего данную функцию.
  41. Стрелки управления на диаграммах нижнего уровня должны быть детализованы до названия документа, регламентирующего данное действие.
  42. На диаграммах верхнего уровня разрешается использовать названия групп документов только в том случае, если они раскрываются до названия регламентирующего документа на нижних уровнях декомпозиции. Все прочие условия (кроме регламентирующих документов) должны быть показаны на диаграмме как обычные входы, а не как стрелки управления.



  1. Правила формирования моделей бизнес-процессов в IDEF3



  1. Формат IDEF3 применяется для описания бизнес-процессов в виде потоков операций (работ).
  2. Условные обозначения формата IDEF3 представлены в следующих таблицах 3 и 4.






Наименование

Описание

Графическое представление

1

Процесс (операция, работа)

Объект служит для описания операций (работ), выполняемых подразделениями/сотрудниками предприятия.




2

Ссылочный объект

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






Таблица 3




Тип стрелки

Графическое представление

1

Стрелка предшествования. Соединяет последовательно выполняемые операции.




2

Стрелка отношения. Используется для привязки объектов-комментариев к операциям.




3

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





Таблица 4

  1. Операции (работы) обозначают преобразования потоков материальных, финансовых ресурсов и информации (документов, файлов).
  2. Операции изображаются прямоугольниками со сплошными границами и прямыми углами, при этом нижняя часть прямоугольника отделена сплошной линией.
  3. Каждая операция имеет название и уникальный номер.
  4. Название операции выражается глаголом или отглагольным существительным.
  5. Номер операции используется для ее идентификации в модели.
  6. Стрелки связей обозначают взаимосвязи между выполняемыми операциями, которые могут выражаться через связь операций посредством потока объектов или последовательность выполнения операций во времени.
  7. Связь между операциями, выраженная как последовательность выполнения во времени может быть двух видов:
    1. старшая связь;
    2. связь-отношение.
  8. Старшая связь показывает, что для начала работы одной операции необходимо завершение выполнения другой. Старшая связь изображается однонаправленной сплошной стрелкой с одним наконечником.
  9. Связь-отношение показывает, что для выполнения операции нет необходимости в завершении выполнения другой операции . необходимо только начать выполнение этой операции. Связь-отношение изображается однонаправленной пунктирной стрелкой с одним наконечником.
  10. Рекомендуется строить диаграммы IDEF3 так, чтобы стрелки, обозначающие связи были направлены слева направо, либо сверху вниз.
  11. Стрелки изображаются вертикальными и горизонтальными отрезками прямых с одним или двумя наконечниками конце, пересекающиеся под прямым углом и сопряженные дугами.
  12. Стрелки соединяются с прямоугольниками, изображающими операции следующим образом:
    1. концы стрелок должны касаться внешней стороны прямоугольника, но не пересекать ее;
    2. стрелки должны подсоединяться к прямоугольнику на его сторонах, присоединение в углах не допускается;
    3. в отличие от IDEF0-диаграмм, стрелки могут подходить и исходить из любых граней прямоугольников.
  13. Объект модели типа «перекресток» используется для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом выполнения следующей операции.
  14. Перекрестки используются для обозначения следующих ситуаций: окончание реализации одной операции может служить сигналом к началу выполнения нескольких операций, или же одна операция для своего запуска может ожидать окончания выполнения нескольких операций.
  15. Стрелки могут сливаться и разветвляться только через перекрестки.
  16. В таблице 5 приводятся типы используемых перекрестков.






Наименование

Описание

Графическое представление

Смысл в случае слияния стрелок

Смысл в случае разветвления стрелок

1

Асинхронное «И»

Все предшествующие

операции должны быть

выполнены.

Все следующие

операции должны быть

запущены




2

Синхронное «И»

Все предшествующие

операции должны быть

завершены одновременно

Все следующие

операции должны быть

запущены одновременно




3

Асинхронное «ИЛИ»

Одна или несколько

предшествующих

операций должны быть

завершены

Одна или несколько

следующих операций

должны быть запущена





4

Синхронное «ИЛИ»

Одна или несколько

предшествующих

операций должны быть

завершены одновременно.

Одна или несколько

следующих операций

запускаются одновременно





5

Исключающее «ИЛИ»

Только одна

предшествующая

операция должна быть завершёна

Только одна

следующая операция

запускается





Таблица 5

  1. Перекресток изображается квадратом, с двойной правой, а иногда и левой границей.
  2. На одной диаграмме IDEF3 может быть создано несколько перекрестков различных типов.
  3. Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой (иначе нет смысла использовать перекрёстки).
  4. Ссылки используются для указания некоторой дополнительной информации об операциях или перекрестках. Ссылки применяются для указания следующих свойств операций и перекрестков:
    1. участия важного объекта в выполнении операции;
    2. циклов выполнения операций;
    3. частоты выполнения операций;
    4. другой важной информации.
  5. Ссылки изображаются прямоугольником, похожим на прямоугольник, обозначающий операцию.
  6. Ссылки соединяются сплошной линией с операцией и перекрестком к которому они относятся.
  7. При построении диаграмм в IDEF3, используется принцип декомпозиции. В результате декомпозиции образуется иерархическая структура диаграмм IDEF3.
  8. Родительская диаграмма, расположенная на вершине иерархической структуры диаграмм, должна быть либо диаграммой IDEF0, либо диаграммой DFD.
  9. В случае, если IDEF3 диаграммы не дополняют IDEF0 модель или DFD модель, а являются самостоятельной моделью, то на указанной родительской диаграмме верхнего уровня должна быть обозначена цель моделирования с точки зрения создателя модели (контекстная диаграмма).
  10. В качестве контекстной диаграммы рекомендуется использовать контекстную диаграмму, выполненную в IDEF0 нотации.
  11. Диаграммы должны содержать не менее 3 и не более 8 операций.
  12. Связь через потоки объектов должна иметь имя, которое является уникальным.
  13. Старшая связь и связи-отношения могут иметь имя.
  14. Каждому перекрестку присваивается уникальный номер.
  15. . При наличии стрелок со сложной топологией иногда целесообразно повторить имя стрелки для удобства ее идентификации.
  16. Каждая операция, не имеющая декомпозиции, помечается небольшой диагональной чертой, расположенной в левом верхнем углу прямоугольника, изображающего эту операцию.
  17. Стрелки должны сливать и разветвляться через перекрестки.
  18. При соединении большого числа прямоугольников необходимо избегать необязательных пересечений стрелок. Следует минимизировать число петель и поворотов каждой стрелки.
  19. Следует обеспечить максимальное расстояние между прямоугольниками и поворотами стрелок, а также между прямоугольниками и пересечениями стрелок для облегчения чтения диаграммы. Одновременно уменьшается вероятность перепутать две разные стрелки.
  20. В случаях сложных диаграмм рекомендуется использовать различные цвета или «уровни» для прямоугольников и стрелок, позволяющие показывать или распечатывать только часть схемы и добиваться её большей наглядности.
  21. Диаграммы должны быть декомпозированы до уровня, на котором присутствуют операции обработки конкретных документов (или совокупности документов).
  22. В ссылках на операции обработки документов должны быть указания на обрабатываемые документы.



  1. Требования к оформлению листа модели бизнес-процесса



  1. Каждая диаграмма модели бизнес-процесса оформляется в виде отдельного листа.
  2. Графически лист модели оформляется так, как показано на рисунке 4 настоящего приложения.





Рисунок 4 Требования к оформлению листа модели бизнес-процесса





Рисунок 5 Диаграмма верхнего уровня IDEF0

Рисунок 6 Контекстная диаграмма IDEF0



Рисунок 7 диаграмма IDEF3



Рисунок 8 диаграмма IDEF3




Рисунок 9 диаграмма IDEF3



Рисунок 10 диаграмма IDEF3

  1. Задание к лабораторной работе



  1. Определить и зафиксировать на бумаге ситуацию, проблему и цели описания бизнес процессов. Очевидно, что в соответствии со спецификой курса целью описания бизнес процессов является автоматизация, а вот автоматизация ЧЕГО и ЗАЧЕМ необходимо определить, поскольку автоматизация ради автоматизации априори обречена на провал.



Пример:

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

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

Цели (автоматизации):
  • организовать учёт не заполненного места в вагонах
  • организовать учёт заказов от третьих компаний
  • автоматизировать отслеживание состояния заказов третьих компаний



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



Пример:

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



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


Оформленные результаты работы, необходимые для защиты лабораторной работы:

  1. Зафиксированную на бумаге ситуацию, проблему и цели описания бизнес процессов.
  2. Распечатанное описание бизнес-процессов компании в нотации IDEF0 и IDEF3.
  3. Список ключевых бизнес процессов, выбранных для автоматизации с обоснованием выбора именно этих процессов для автоматизации для каждого процесса. Для каждого процесса на уровне IDEF0 (для автоматизации дожжен быть выбран как минимум один процесс уровня IDEF0), выбранного для автоматизации, указать критерии эффективности и минимально допустимые критерии эффективности автоматизации. Отдельно указать критерии эффективности для бизнес-процесса нулевого уровня.
  4. Список функции разрабатываемой системы в формате:






Функция

Тип

Поддерживает бизнес процессы

Примечание

1

<функция 1>

Осн/доп

< бизнес процесс 1>,<бизнес процесс 2>,<бизнес процесс 3>…

<Комментарий>
































Вопросы к защите:

  1. Термины и определения, указанные в разделе «Термины и определения».
  2. Условные обозначения формата IDEF0.
  3. Условные обозначения формата IDEF3.
  4. Условные обозначения стрелок.
  5. Перекрёстки в формате IDEF3.
  6. Как бизнес-процесс должен рассматриваться на верхнем уровне?
  7. Что такое иерархия бизнес-процессов?
  8. Правила именования стрелок.
  9. Тунелирование. Что такое? Зачем нужно?
  10. Что такое критерии эффективности?
  11. Зачем нужны критерии эффективности?
  12. Различные вопросы по выполненной работе.



Удачи!

1 Шаблон Концепции Проекта и рекомендации по его заполнению будут представлены отдельным документом. Разработка Концепции проекта осуществляется на второй лабораторной работе. Выбор ключевых бизнес процессов для автоматизации и обоснование выбора, а также определение критериев эффективности для каждого процесса (как минимум, для каждого процесса, выбранного для автоматизации на уровне IDEF0 + критерии эффективности для бизнес процесса нулевого уровня), определение минимальных показателей эффективности выполняется в рамках ЭТОЙ лабораторной работы.