Какую программу выбрать(бизнес-процессы)? #383777

Кто в какой программе рисует бизнес-процессы? Чтоб потом их реализовывать в 1С.

ВИЗИО?

Писчая бумага (tm)

Рисовать можно и в 1С - потом легче реализовывать будет :)

Ну можно и просто голову использовать, я про большие проэкты

я вот в этой пишу и реализую в 1С =)

+

тут не только рисовать можно

(5,6) эта программа весьма неудобна для рисования бп. Дорожки приходиться рисовать самому. При перемещении дорожки элементы не перемещаются. Если надо организовать пул с дорожками тоже самому рисовать. Кроме того в нотации, которая тут применяется многих полезных вещей нет, которые есть в BPMN. Самое модная нотация - BPMN. Хорошо для этого подходит Enterprise Architect (сам использую) либо BizAgi Process Modeler. В BizAgi Process Modeler очень хорошо реализован BPMN, но больше ничего нет. В EA BPMN менее удобен - зато в одной программе UML, BPMN и другие полезные нотации (DFD, расширения UML для проектирования БП и прочие).

ключевое слово тут "1С"...

а чем визио плох?

заказчику глубоко все-равно в какой программе нарисованы БП. Нужен качественный документ. Не вижу смысла терпеть неудобства.

да в принципе ничем не плох. Я посоветовал то, чем сам пользуюсь. Знаю что есть расширения для визио для BPMN - но сам не смотрел их.

внимательно читаем

Постановка вопроса предполагает средство анализа для проектирования БП с последующей их реализацией (т.е. разработкой) в 1С. Автор же не спросил какую программу для ИСПОЛНЕНИЯ БП применяют.. Если такая постановка вопроса - то ИМХО Инталев.

BPWIN, ARIS

вообще я не понимаю зачем нужно рисовать большие схемы, есть правило, что в БП не должно быть более 7 элементов (ну до 11 по другим методам), если больше, то делаеться вложенный процесс. А вложенные довольно неплохо в самой 1с делать.

BPWIN+ERWIN - ИМХО прошлый век. UML+BPMN = будущее)))

*поставил себе в планы интегрировать в BPMN редактор*

Если уж так нравится BPMN - зачем использовать именно BizAgi PM?.. Во первых это еще довольно сырая программа. Во-вторых на рисовании все и закончится (или будешь покупать BPMN от этой же BizAgi??) а потом будешь мучаться с выгрузкой русского шрифта в PDF... Предлагаю Intalio там все бесплатно и опенсорс. и BPMN-рисовалка и BPM вместе с SOA -) А там хоть 1С, хоть SAP, хоть Dynamics.. Если интересует статистика по России - подавляющее большинство "рисуют" в пиратском Visio, и в банальном MS Word. Причем в ворде чаще. Дальше идет ARIS/BPWin. Потом UML. "Будущее" еще далеко.

+ В BPMN-е рисуют для того, чтобы потом автоматизировать процессы в BPMS. А в спрашивали "чтобы потом реализовывать в 1С". Не смотря на то, что под "реализовывать в 1С" можно понимать как автоматизацию нарисованных процессов, так и доработку конфигурации, я все же догадываюсь что имели ввиду второе. А для этих целей гораздо удобней использовать SADT или уж UML в зависимости от ориентированности. Причем те, кто рисует в UML - спрашивал ли программистов, по каким схемам им понятней и удобней писать код - по объектным или по BPWin-овским? Я всегда считал, что по BPWin-овским. Если цель подразумевалась цель первая (автоматизация БП в 1С) - то в этом плане более чем конкурентоспособная альтернатива.

Intalio посмотрю. Но просто BizAgi нравиться)) BPMN и Activity в UML очень похожи - их даже разрабатывает одна организация. Только в BPMN есть дополнительные возможности, например указание таймера. В UML от Rational Rose есть возможность указывать состояния на диаграммах Activity - вот собственно и вся разница. А бизнес процессы описываются не для программистов. Из бизнес процессов правильно выявлять требования, которые потом уже реализуют программисты. Так что главная ориентация - что бы было понятно заказчику. Т.е. правильно цепочку сделать так: 1: BPMN + class UML + activity UML -> 2: use case UML + class UML + state chart UML -> 3: class UML + state chart UML + collaboration UML -> 4: activity UML. Расшифровка: 1. Бизнес процессы + бизнес сущности + бизнес-правила. 2. Требования (варианты использования) + логическая модель + состояния системы 3. Структура метаданных + состояния регистров и статусы документов + структура ввода на основании 4. Представления алгоритмов Я не навязываю наш метод анализа и проектирования, но утверждаю, что путем долгого эксперементирования над нашими заказчиками, разработанная методология "СОРАТНИК", наиболее отвечает потребностям внедрения ИС на 1С.

- Толку от указания таймера нет до тех пор, пока сам таймер не будет отрабатывать в реальном времени. Для наглядности я могу и в ворде нарисовать какую угодно декорацию.. - Бизнес-процессы - не для программистов, но функционал при этом просто "потом уже реализуют программисты". Простая и понятная связь бизнес-IT. - Главная ориентация на заказчика с использованием бизнес-процессов в условиях кризиса может быть в предоставлении возможности выявления неэффективностей в бизнес-процессах и их совершенствование через анализ схем БП. Для этого схемы БП должны соответствовать действительности и быть достаточно детализированы. - Идея "будущего" - отказ от такого большого количества схем и нотаций (поднотаций), да и от проектирования приложений для реализации/модификации бизнес-процесса вообще. Отказ от длительного цикла разработки/тестирования модифицированного ПО. "Просто" меняешь схему в BPMN и по мановению волшебной палки система уже работает по-новому. =) Волшебная палка (по другим источникам - серебряная пуля) меняет и бизнес-логику, и порядок выполнения операций и пользовательский интерфейс и внешний вид отчетов... чудеса..

>> "Просто" меняешь схему в BPMN и по мановению волшебной палки система уже работает по-новому Такого точно не будет. Логику все равно придется реализовывать. Лучшее, что будет - это встраиваение систем выполнения в ERP системы, как в BAAN или SAP. 1С в этом направлении тоже движеться - Инталев, вы и питер-софт уже выпустили чего-то похожее. >> Главная ориентация на заказчика с использованием бизнес-процессов в условиях кризиса может быть в предоставлении возможности выявления неэффективностей в бизнес-процессах и их совершенствование через анализ схем БП. Для этого схемы БП должны соответствовать действительности и быть достаточно детализированы. БП всегда должны соответствовать действительности, иначе зачем они нужны. Но тут есть разница подходов. Мы не занимаемся реинжинирингом и вряд ли для этого спрашивал программы для описания БП - наша задача внедрить ИС и с этой точки зрения БП нужны для выявления требований к ИС. Требования - главная основа любого проекта и работать с ними надо очень тщательно. Ошибка в требованиях может привести к срыву проекта. Описание БП на этапе анализа позволяет не пропустить важных функциональных требований. >> Толку от указания таймера нет до тех пор, пока сам таймер не будет отрабатывать в реальном времени. Для наглядности я могу и в ворде нарисовать какую угодно декорацию.. А зачем изобретать велосипед, если уже все изобретено? Таймер - вещь очень полезная. Например при разработки больших аналитических подсистем полезно знать примерное время, когда данные будут требоваться. Например, если в текущем месяце анализируются затраты предыдущего месяца - тогда можно анализировать уже результаты после "закрытия месяца", а если нужна оценка затрат текущего месяца - то нужен будет отчет вроде "Анализ распределения производственных затрат" из УПП. Т.е. это так же позволяет не пропустить важных требований к ИС. От "большого количества схем и нотаций" все равно не уйдем - програмный продукт как здание имеет много различных чертежей. Только в случае со зданием все относительно понятно - за много тысяч лет научились строить и проектировать. А в случае с програмным продуктом пока идет развитие - UML наиболее отвечает потребностям проектирования ПО - мы просто немного адаптировали его для 1С.

Я может не понял топикстартера, а может специально искажаю его вопрос ) Ключевое слово тут "бизнес-процессы". У меня такое ощущение, что человек не хочет проектировать ПО. Он не хочет строить здание. Он хочет в этом здании (построенном уже) бизнес-процесс поменять/документировать/привнести. Это примерно как создание или изменение схемы пожарной безопасности - по каким лестницам бежать на выход в случае ЧП и где лежит огнетушитель. Схемы тут достаточно одной и нотации тоже (читай BPMN). Не нужно строить здание с нуля или перестраивать у него один-два этажа. Скажете, что слишком специфичный бизнес-процесс я тут на коленке изобразил и для другого понадобится обязательно другая схема? Ну так BPMN - это достаточно универсальная вещь. И она поддерживает достаточное количество технических деталей: это то, о чем вы говорили, про логику, которую придется все равно реализовывать. На одной логике возможности, разумеется, не заканчиваются.

+ Еще раз убеждаюсь в том факте, что когда люди говорят о "бизнес-процессах в какой-то информационной системе", в частности про их моделирование, они обязательно подразумевают под этим разработку ПО с нуля или основательную его кастомизацию. По проектной технологии. Редко когда подразумевают собственно моделирование бизнес-процессов с целью их дальнейшей автоматизации.

Советую Инталев.

А для меня ключевые слова в теме "Чтоб потом их реализовывать в 1С."

К сожалению 1С-ги в большенстве своем именно "не хотят строить здание и не хотят проектировать ПО".

А потом приходиться рaзгребaть пoделки десятка программистов. Один слева прилeпил, второй справа, четвертый сверxу настроил. Вроде как оно на "здание" системы не влияет - но уж очень вид портит... Мы применяем описание БП именно для последущей автоматизации процессов - тут мы с вами расходимся в назначении моделирования - мы не консалтинговая организация - мы внедренцы и разработчики ПО. Но считаю, что даже для малых изменений в ИС (сложнее изменения печатных форм) полный цикл обследования обязателен. Описанием одного среза в случае изменения ИС не обойтись. Просьба пользователя "добавить галочку в документ, а потом  в отчет" часто влечет за собой много всего..

(27, 28, 29) P.S. разбил потому что мат фильтр не пропускал. Модераторы, занесите, что слово "разгребAть" не является матным!

Сейчас начнут спрашивать, кто такой Гр... :)