КСК.ИК помогает быстро увидеть рабочий процесс. Как получить результат и не впасть в бесконечные переделки

При проектировании бизнес-процессов перед разработчиками встаёт проблема - насколько адекватными будут маршруты, все ли данные учтены, правильно ли распределены роли участников. Безусловно, у специалистов существуют свои методы выбора альтернатив.

BPMS-платформа КСК.Интеллектуальный конвейер (КСК.ИК) даёт дополнительную степень свободы - возможность воочию увидеть спроектированную версию бизнес-процесса. Как выражается один из известных консультантов: «Надо запустить реальный процесс, чтобы летало и мыргало». Такой подход упрощает понимание участников, что они получают, - смотреть в информационной системе куда нагляднее, чем на бумаге. Пользователи и владелец бизнес-процесса обсуждают собственно маршрут прохождения, данные в формах, справочники. По итогам рассмотрения и обсуждения можно вносить правки и выпускать новую версию маршрута. Напомним, что в КСК.ИК поддерживается логика low code, то есть разработка маршрута и форм бизнес-процесса визуальными средствами; ведётся история процессов; перенос процесса из среды разработки в продуктивную среду производится переносом файла процесса.

С другой стороны специалисты «КСК ТЕХНОЛОГИИ» иногда сталкиваются с ситуацией трудности перехода от проектирования к внедрению бизнес-процесса. Владелец нового бизнес-процесса всё время улучшает и модифицирует описание «на берегу». Можно привести несколько маркеров такого поведения:

а) информационная модель объекта изменяется в минимальной степени при выпуске новой версии процесса;

б) выпущено более пяти версий процесса.

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

1. Ведение Таблицы с результатами обкатки для фиксации результатов пилотной эксплуатации (структура таблицы приведена ниже).

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

3. Анализ выявленных замечаний с учетом степени значимости и предложение возможных решений.

4. Ведение статистики результатов опытной эксплуатации.

5. Подведение итогов обкатки с ключевыми участники, подписание протокола.

Структура таблицы:

1) номер замечания;

2) дата и время;

3) автор;

4) описание замечания:

4.1) краткое описание проблемы;

4.2) на что влияет или чем грозит;

4.3) критичность;

5) мера по устранению или предотвращению;

6) результат устранения.

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

Напомним внешний вид Дизайн-студии: