Диссертация (1152223), страница 58
Текст из файла (страница 58)
Т. Корсон предложил рассматриватьиерархию вариантов использования, показал, что вариант не является результатом функциональной декомпозиции процесса [267], но не предложил путь к выявлению процесса.Что бы сделать схему процесса читаемой и понятной, Б. Сильвер предлагает создавать иерархическую модель, где верхний уровень даёт общее представление о процессе, показывает его взаимодействие с другими процессами, а также c внешними сущностями, образующими окружениепроцесса. Все детали исполнения процесса должны быть «скрыты» на нижних уровнях декомпози-223ции [227]. Идея абсолютно правильная, однако остаётся непонятно, как построить иерархию процесса, раскрывая его снизу-вверх.
Дело в том, что аналитику трудно понять, по какому принципунадо группировать операции в подпроцессы, которые выносятся на верхний уровень модели.В рамках структурных методов проектирования информационных систем широко применяется метод проектирования сверху вниз с использованием нотаций моделирования IDEF0,DFD, пр.
В этих случаях, обычно, используется функциональная стратегия декомпозиции.Например, авторы методологии SADT рекомендуют использовать функциональную декомпозицию [127] и не использовать разложение «по физическому процессу». Они отмечают: «результатом декомпозиции по процессу может стать слишком детальное описание системы, котороене будет в полной мере учитывать ограничения, диктуемые функциями друг на друга. При этомможет оказаться скрытой последовательность управления».
Поэтому они рекомендуют этустратегию, только «в крайнем случае, когда не понятно, как действовать» [127]. Таким образом,полученные модели следует классифицировать как функциональнее, а не процессные. Итак,сложности, возникающие при раскрытии процессов снизу-вверх, предсказаны в SADT и предопределены выбором стратегии декомпозиции. Мы, забыв их предупреждение, повторно сталкиваемся с известной проблемой.Метод структурного анализа процессов (Structured Process Analysis, SPA), описанныйМ.
Робсоном и Ф. Уллахом [268], предлагает начать выявление процесса с нахождения данных,которыми обмениваются структурные подразделения компании. Для этого, выполняется структурная декомпозиция организации, с целью выявить организационные единицы. Затем, с помощью диаграммы потоков данных выявляются информационные потоки, связывающие этиподразделения. Процесс делится на подпроцессы по зонам ответственности, в результате оказывается, что работы процесса оказываются привязанными к структурным подразделениямкомпании. Затем процесс структурного подразделения декомпозируется на отдельные работы.Авторы предлагают дополнить модель процесса справочником работ, считая последний «важным инструментом предотвращения ошибок и неточностей, которые могут случиться, еслиописывать разные, но похожие выходы процесса одними и теми же терминами». Можно отметить целостный подход авторов к выявлению процессов, но нельзя не заметить, что разделениесквозного процесса на подпроцессы структурных подразделений отражает, скорее, взглядыфункционального менеджмента, а не процессного.Идентификация процессаМы будем рассматривать моделирование с использованием диаграммы потоков работ, будем строить методику раскрытия процесса сверху вниз в рамках системного подхода.
Обычнопроцесс связан с некоторым объектом, который подвергается обработке по ходу процесса и на224выходе формирует некоторый продукт. Например, выдача банковского кредита начинается собработки заявки клиента, а процесс предоставления услуги телекоммуникационной компанииначинается с заказа. Что бы выявить границы процесса, следует начать с рассмотрения фазжизненного цикла соответствующего объекта. Например, банковский кредит имеет следующиефазы жизненного цикла: (а) «Принять решение о выдаче кредита по заявке»; (б) «Обслуживатькредит» (зарегистрировать кредитный договор в БИС, выдать заем, принимать платежи, рассылать уведомления и т.
д.); (в) «Взыскать задолженность»; (д) «Закрыть кредитный договор»,причём каждый этап связан со своим объектом. Границы анализируемого процесса могут несовпадать с рассматриваемыми этапами жизненного цикла. Например, процесс «Принять решение по заявке» совпадает с границами соответствующей фазы. А процесс «Выдать кредит» объединяет фазу «Принять решение по заявке» и два подпроцесса второй фазы «Зарегистрироватькредитный договор в БИС» и «Выдать заем».
В таком объединении нет ничего плохого, еслианалитик отдаёт себе отчёт в результатах.Далее процессу надо выбрать название, оно должно отражать его основную цель и определять результат. Рассмотрим ситуацию, когда клиенту отказывают в выдаче кредита. Для процесса «Выдать кредит» отказ рассматривается как брак, поскольку результат не достигнут, адля процесса «Принять решение по заявке» любое обоснованное решение, включая отказ, рассматривается как успех, а браком считается ошибочное или запоздалое решение. Изменяяназвание процесса, мы тем самым корректируем его границы.Если процесс шире этапа жизненного цикла, все покрываемые фазы следует явно выделить, в модели процесса они образуют цепь взаимодействующих подпроцессов [179].
Еслипредполагается автоматизировать только часть этапов жизненного цикла, выбранный фрагментнадо рассматривать в контексте всего цикла, ведь в конечном итоге нас будет интересовать достижение главной цели, а не промежуточного результата. К тому же, нас интересует управлениевсем процессом, а не фрагментом. Недостаточно ограничить длительность этапа, он может исполняться вовремя, тогда как весь процесс целиком с опозданием из-за повторного исполненияэтапов.
Таким образом, аналитик должен рассмотреть процесс в контексте этапов жизненногоцикла соответствующего продукта, понять, совпадают ли границы процесса с этими этапами.Объект управленияРанее, на основании анализа онтологии Бунге-Ванда-Вебера было показано, что процессописывает последовательность изменения состояния системы во времени». В производственном процессе фиксируются изменения состояния материального продукта.
Но в бизнес-процессе изменение состояния системы фиксируется в информационных объектах [199]. Один изинформационных объектов будем называть основным, если он:225Является ключевым для данного бизнес-процесса;Связывает вход и выход процесса;Может содержать (ссылаться на) другие информационные сущности;Когда мы говорим, что объект является ключевым для процесса, имеем в виду, что онфиксирует результат исполнения очередной операции, отдельного этапа или всего процесса целиком и передаёт его на вход следующей операции, этапа или процесса.
Тем самым, он связывает выходы и входы. Вспомогательными будем называть остальные информационные объекты, которые фиксируют изменения данных, но не результат выполнения операций.Объект управления играет роль переменной состояния, которая определяет статус всейсистемы в данный момент времени, его движение будем трактовать как поток управления, егоприбытие определяет начало исполнения соответствующей операции.
Предложим выделять совокупность смежных работ, ссылающихся на один и тот же документ или информационнуюсущность, которую можно трактовать как объект управления. Таким образом, мы разобьёмсквозной процесс на фрагменты, каждый со своим объектом управления.Метод чередования стратегии декомпозиции при выявлении процесса.Выявление процесса сверху вниз нужно осуществлять последовательно. Будем применятьдекомпозицию по функциям, а затем по этапам жизненного цикла объекта управления. Такимобразом, мы построим верхний уровень модели процесса. Аналитик пока не должен стремитьсяк глубокой степени детализации.
Далее мы обсудим критерий глубины раскрытие процесса.Выявление нормативного сценария исполнения.Нормативным (Happy path) мы договорились называть такой сценарий выполнения процесса, в ходе которого все операции завершаются результативно и с приемлемым качеством,никаких отклонений в исполнении процесса не наблюдается. Следуя определению, работы,включённые в нормативный сценарий связанны только безусловными переходами, ветвленийна схеме нет.
Что бы выявить нормативный сценарий следует создать структурную декомпозицию работ, затем расположить работы в порядке очерёдности их исполнения.Согласно А. Кобэрну, исполняя процесс, мы преследуем определённую цель [258]. Напервом этапе главную цель следует декомпозировать на задачи, которые подлежит решить, чтобы процесс завершился успешно. Для каждой задачи определим результат, который свидетельствует, что задача решена и цель достигнута.
Теперь можно переходить к декомпозиции по этапам жизненного цикла.Декомпозиция по этапам жизненного цикла помогает расположить работы процесса в порядке их исполнения. Эта декомпозиция не предполагает анализа ветвлений процесса, этапы226располагаются в естественном порядке следования, они связаны безусловными переходами. Мыможем оформить каждый этап как подпроцесс, тогда нормативный сценарий будет изображаться цепочкой подпроцессов, связанных безусловными переходами.ПроцессПодпроцесс 1Подпроцесс 2Подпроцесс 3Подпроцесс 1Основной сценарий исполнения Happy pathРисунок 4.13 - Нормативный сценарий исполнения процессаИсточник: составлено автором.Нормативный сценарий не предполагает показывать альтернативные варианты исполнения и ветвления.
Поэтому следующими шагами модель следует уточнить: (а) расширить — добавить в нормативный сценарий пропущенные варианты исполнения, (б) углубить — детализовать каждый из подпроцессов.Каждый этап связан с решением соответствующей задачи. Результат выполнения этапахарактеризуется с помощью показателей продукта. Продолжение процесса зависит от результата завершения очередного этапа, рассмотрим два сценария:–Ожидаемый результат этапа достигнут — нормальное продолжение;–Результат не достигнут — это брак.Рассмотрим оба варианта продолжения по отдельности.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
