Форум сервиса Планфикс

Господа, у нас возникла проблема при написании и описании наших бизнес-процессов с помощью сценариев.

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

Наши проблемы с "работающими" сценариями, в нашем случае возникают по следующим причинам:

1. сложные бизнес процессы, на которые сценарии изначально не рассчитаны (у нас много задач в одном бизнес процессе и выполнение отдельных сценариев зависит от текущего состояния многих задач);
2. постоянное изменение и доработка бизнес процессов (т.е. изменение наборов статусов, порядка создания задач или изменения статусов других задач и т.п., при этом сложно не внести изменения, а найти то место, куда вносить изменения, а также сложно проверить на что влияют эти изменения);
3. сложность процесса отладки, т.к. нельзя сделать тестовую копию ВСЕГО планфикса, на которой можно было бы тренироваться, а затем отлаженные процессы перенести (накатить) на рабочую версию;
4. любое, даже незначительное, изменение в большинстве случаев требует обязательного многократного тестирования ВСЕГО бизнес процесса (всей группы сценариев), т.к. внесенные изменения могут вызывать ошибку и отказ в работе сценария на более поздних этапах, по сравнению с измененным этапом

Текущая архитектура реализации сценариев работает для простых задач/процессов

Вопрос заключается в том, чтобы сценарии вы реализовали на другой логике, желательно в виде объекто-ориентированного программирования. Это бы убило 2 зайца:

1. упростило бы написание и отладку этих сценариев
2. работать со сценариями смогли бы бизнес-аналитики (или люди им подобные)

+ Поддержу. Нужен Visual Basic :)

Я тоже могу пофилософствовать. Всё так абстрактно. Примеров не хватает для предметного разговора.

сложные бизнес процессы, на которые сценарии изначально не рассчитаны (у нас много задач в одном бизнес процессе и выполнение отдельных сценариев зависит от текущего состояния многих задач);

Любой процесс можно по разному разбивать на статусы и этапы. Т.е. либо слишком детально, либо укрупненно. Попробуйте начать с простого.

сложность процесса отладки, т.к. нельзя сделать тестовую копию ВСЕГО планфикса, на которой можно было бы тренироваться, а затем отлаженные процессы перенести (накатить) на рабочую версию;

Совет: двигайтесь маленькими шагами. Изменили чу-чуть, проверили всё ли нормально. И т.д. Сомнительно выглядит заведение тестового аккаунта для этого. Хотя, если много времени, почему бы и нет.

Я в восторге от сценариев и возможностей автоматизации. Это моя любимая часть Планфикса. Некоторых возможностей нам не хватает, о чём писал на форуме, но в целом очень классный инструмент - сценарии.
Но я понимаю о чём говорит автор топика. Когда строишь большой автоматизированный процесс и через месяц тебе нужно внести какую то правку, то очень долго морально готовлю себя к этому... потому что нужно войти в особый режим ниндзя, чтобы восстановить в памяти как всё устроено, найти место внедрения новой возможности и быть ПРЕДЕЛЬНО внимательным, чтобы не налажать и не испортить всё людям, которые работают с этим процессом... Реальные задачи и работа людей может быть разрушена из-за случайной ошибки.Тестовой среды действительно не хватает...

Андрей Гринюк, спасибо за общие советы)
наш (один из) бизнес процесс описывается 70ю шаблонами

Михаил Храпунов - люто плюсую

 

наш (один из) бизнес процесс описывается 70ю шаблонами

Мое первое предположение заключается в том что судя по всему как то не совсем верно у вас выделены эти "бизнес-процессы". Как бизнес аналитик я рекомендую к ним внимательно присмотреться, вполне возможно что один бизнес процесс можно разделить на несколько  подчиненных процессов. Тогда можно выстроить логику через создание подчиненных проектов/задач, тогда на один шаблон будет меньшее количество процессов чем 70 *это какое-то запредельное количество, вы не упомянули шаблоном чего - задач, проектов?

Peter Dudin писал(а): ↑

24.10.2017 19:36

Господа, у нас возникла проблема при написании и описании наших бизнес-процессов с помощью сценариев.

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

Наши проблемы с "работающими" сценариями, в нашем случае возникают по следующим причинам:

1. сложные бизнес процессы, на которые сценарии изначально не рассчитаны (у нас много задач в одном бизнес процессе и выполнение отдельных сценариев зависит от текущего состояния многих задач);
2. постоянное изменение и доработка бизнес процессов (т.е. изменение наборов статусов, порядка создания задач или изменения статусов других задач и т.п., при этом сложно не внести изменения, а найти то место, куда вносить изменения, а также сложно проверить на что влияют эти изменения);
3. сложность процесса отладки, т.к. нельзя сделать тестовую копию ВСЕГО планфикса, на которой можно было бы тренироваться, а затем отлаженные процессы перенести (накатить) на рабочую версию;
4. любое, даже незначительное, изменение в большинстве случаев требует обязательного многократного тестирования ВСЕГО бизнес процесса (всей группы сценариев), т.к. внесенные изменения могут вызывать ошибку и отказ в работе сценария на более поздних этапах, по сравнению с измененным этапом

Текущая архитектура реализации сценариев работает для простых задач/процессов

Вопрос заключается в том, чтобы сценарии вы реализовали на другой логике, желательно в виде объекто-ориентированного программирования. Это бы убило 2 зайца:

1. упростило бы написание и отладку этих сценариев
2. работать со сценариями смогли бы бизнес-аналитики (или люди им подобные)

Разделяю претензии автора,
Есть мнение, что реализовать описание более сложных процессов возможно через реакцию процесса на логику фильтра, например если (1 и 2 то = А), а если (1и 3 то = В) и другие варианты, тогда можно вводить иерархию и шаги в процес.

на сегодня, логика фильтра позволяет спроектировать только один шаг.