2. Дизайн информационной системы
Ссылка на 1-ю часть статьи. Типовая идея моделирования программы состоит в том, чтобы разбить ее на как минимум три составляющие: процессы, данные и непосредственно структура приложения [8-9]. Аналогичным образом поступают при построении ИТ-архитектуры в методологиях TOGAF, POSIX, методе Захмана и др. Последуем этому примеру и рассмотрим все требования через призму указанных составляющих.
2.1. Проектирование бизнес-процессов в моделях AS-IS и TO-BE
В ИТ кругах общеизвестным является тот факт, что организационная структура и бизнес-процессы предприятия, задающие бизнес-архитектуру, проектируются в двух базовых моделях: AS-IS и TO-BE. Для моделирования применяют CASE-средства, включающие в себя графические нотации как верхнего (ARIS VACD, IDEF0, BCM), так и нижнего (Cross WFD, BPMN SLD, UML AD, ARIS eEPC, IDE3 и DFD) уровней проектирования [10].
Теперь давайте разберемся, для чего же нужна AS-IS модель. Следуя модели зрелости компании, описывающей необходимость проектирования бизнес-процессов в зависимости от степени ее развития, обосновывается потребность в AS-IS схеме. Именно она позволяет спроектировать текущие подпроцессы и как следствие выявить «узкие места» в работе предприятия [11]. Цена вопроса – трудозатратное проектирование более чем 10 000 операций в выбранной графической нотации. Выполняя реинжиниринг процессов, TO-BE модель призвана исправить найденные недостатки. Однако, в случае внедрений крупных информационных систем типа ERP/ERP2 основной акцент TO-BE модель преимущественно делает на последовательное описание логики выполняемых операций одновременно с детальным разграничением ответственности сотрудников [12]. Следовательно, если принято решение о имплементации ERP-систем, потребность в AS-IS моделировании фактически отпадает.
Аналогичным образом проанализируем нотации моделирования бизнес-процессов в TO-BE модели. Разделение на верхнеуровневые и низкоуровневые графические схемы позволяет подойти к вопросу обсуждения процессов сверху вниз. Так как нотации проектирования на верхних уровнях не содержат деталей выполняемых операций по определению, их использование может быть легко заменено на подготовку карты процессов соответствующих уровней, пример которой дан в таблице 1.3. Схожим образом дело обстоит с низкоуровневыми нотациями: проектирование операций может быть замещено проработкой схемы процессов, в частности, если последовательность шагов и ответственность второстепенны.
Суммируя все вышесказанное, ограничимся в рамках проектирования лишь доработкой карты бизнес-процессов модели TO-BE. Но и здесь можно сократить объем выполняемых работ: карты процессов AS-IS и TO-BE практически совпадают для операций 1-3 уровней, где степень детализации минимальна. Проработка схемы про-цессов в TO-BE потребуется лишь для уровней 4-е и ниже, хотя на практике даже 3-го уровня детализации бывает достаточно. А чем, собственно, нам поможет карта процессов 4-го уровня? В-первую очередь она используется для проверки того, все ли операции реализованы в программе, во-вторую – подготовки тестовых сценариев приемочных испытаний, и, наконец, – управления изменениями в виде обучения сотрудников.
В ходе проработки бизнес-потребностей операции, отраженные на 3-м уровне карты процессов из таблицы 1.3, были детализированы. Это позволило зафиксировать подпроцессы 4-го уровня, максимально приближенные к исходным требованиям (таблица 1.1.). Результаты обогащения карты процессов на 4-м уровне даны в таблице ниже.
Табл. 2.1. Фрагмент карты процессов в модели TO-BE
Полный текст статьи: https://corpinfosys.ru/archive/2022/issue-18/198-2022-18-noncodeintegral
