Введение
Одной из важных задач при имплементации корпоративных информационных систем является проектирование бизнес-процессов. Следуя [1], в ERP-проектах выделяется отдельный уровень внедрения: уровень процессов. Здесь ведется моделирование бизнес-процессов на основе общеизвестных графических нотаций, строятся модели As-Is и To-Be. Все разнообразие нотаций моделирования объединено термином CASE-средства, суть которых изначально заключалась как в проектировании, так и последующей автоматизации настроек и разработок ERP-систем [2].
На сегодняшний деть имеется множество всевозможных нотаций моделирования бизнес-процессов, каждая из которых обладает своим набором уникальных графических элементов, особенностями и областью применения. Не все нотации изначально создавались под нужны ERP-проектов, поэтому их использование при проектировании корпоративных информационных систем не всегда разумно. Имплементация информационных систем – задача весьма специфичная и трудоемкая, поэтому выбор нотации должен вестись весьма осознанно.
В принципе, применение неподходящего CASE-средства не так критично, однако это приводит к излишним трудозатратам, так как построенные схемы процессов будут содержать излишние или наоборот недостающие графические элементы, важные для конечных пользователей. Исходя из этого, необходимо разбираться в тонкостях нотаций моделирования и четко разграничивать область применения каждой. Именно это задачей мы с вами и займемся в рамках данной работы.
1. Цель и задачи
Цель статьи заключается в анализе методов проектирования бизнес-процессов, применимых к проектам внедрения ERP-систем. Использование подходящих графических моделей позволит строить наглядные процессные диаграммы, удобные для конечных пользователей, что облегчит им работу с разрабатываемой программной системой. Достижение цели потребует решения таких задач, как:
- рассмотрение бизнес архитектуры предприятия;
- обзор способов проектирования организационной структуры и процессов;
- анализ наиболее приемлемых нотаций моделирования для ERP-проектов.
2. Бизнес архитектура предприятия
Описание процессов не является самоцелью, есть вещи высших порядков. Одной из которых является архитектура предприятия. Не важно, какой подход выбран для построения архитектуры: TOGAF, метод Захмана, POSIX или Gartner, существенно то, что в ней выделяют такие области, как техника, приложения, данные и бизнес [3]. Бизнес архитектура в общем случае представляет собой совокупность организационной структуры предприятия, а также бизнес-процессов.
Зачем вообще моделировать оргструктуру и процессы компании? Для ответа на этот вопрос воспользуемся моделью зрелости компании, в которой выделяют этапы развития: начальный, управляемый, стандартизированный, предсказуемый и постоянно улучшаемый. Этапам развития соответствуют уровни зрелости процессов: хаотичные, описанные, контролируемые, интегрированные и проактивно управляемые. Таким образом, моделирование процессов – это отправная точка для стандартизации и улучшения выполняемых операций как нашей компании, так и организации контрагента.
Существует множество способов, позволяющих улучшать бизнес-процессы компании, к ним можно отнести такие методы, как:
- BSP (Business system planning), позволяющий строить информационные системы для удовлетворения потребностей предприятия на основе данных;
- CPI (Continuous process improvement) или TQM (Total quality management), призывающий к постоянному совершенствованию качества товаров, обучению и отказу от контроля;
- CMM (Capability maturity model), улучшающий процесс разработки и контроля качества программного обеспечения;
- BPR (Business process reengineering), подразумевающий радикальное перепроектирование бизнес-процессов компании на регулярное основе;
- ERP (Enterprise resource planning), за счет применения существующих бизнес функций и объектов программной системы.
Обратите внимание, что внедрение ERP-систем также рассматривается как средство совершенствования бизнес-процессов организации. Обычно моделирование ведется в двух моделях: As-Is и To-Be, первая из которых описывает работу предприятия до изменений, вторая – после внедрения решения по улучшению.
Проектирование процессов требует их итерационную детализацию. Так на начальных этапах моделирования бизнес-процессы описываются достаточно обще. Далее производится процедура дихотомической декомпозиции каждого процесса на подпроцессы, а каждого подпроцесса на операции. С увеличением уровня декомпозиции, увеличивается степень детализации, в итоге от описания работы компании в целом осуществляется переход к проектированию операций, выполняемых конкретными сотрудниками. Согласно [4], на уровнях детализации 6-8 число операций для описания достигает размера более 10 000.
Основными сложностями проектирования процессов в As-Is являются: большое число подпроцессов для описания, постоянное изменение процессов даже в момент их проектирования, высокая потребность в привлечение бизнес-пользователей. Поэтому в проектах внедрения ERP-систем достаточно часто ограничиваются лишь моделированием оргструктуры и бизнес-процессов только в To-Be. Начнем обзор бизнес архитектуры предприятия с рассмотрения методов проектирования его оргструктуры.
Полный текст статьи: https://corpinfosys.ru/archive/issue-4/134-2018-4-processes
