Библиотека

Для полноты изложенного материала, хотелось бы добавить, что по каждому типа процесса в Business Studio изначально есть отчет "Проверка правильности построения диаграммы... ".
Оно так же проверяет некоторую "орфографию" моделирования процесса.

>>Если
вы с помощью контекстного меню скопируете блок на диаграмме, а затем вставите его на этой
или другой диаграмме – вы создадите не новый подпроцесс, а всего лишь экземпляр
существующего процесса. При изменении одного экземпляра процесса будут меняться и прочие
экземпляры процесса. См. рис. 2.23.

Это не так, будет именно копия.

Привет, коллеги!

Прочитал статью. Спасибо Александру за большой труд. Особенно наглядные иллюстрации к статье - сразу видно, что именно нужно смотреть на скринах системы. С точки зрения обучения продукту статья, имхо, полезна.

Однако переход от простых вещей (навигатор и т.п.) к сложным (вывод в отчет "Шахматки") происходит как-то уж очень резко. Кроме того, почти половина статьи посвящена изложению правил бизнес-моделирования в целом. Возможно, стоило бы подчеркнуть именно особенности бизнес-моделирования в BS, а не общие.

Несколько мыслей по тезисам статьи.

1. Согласен с Александром, что справочник процессов в BS может заменить модель VAD. Но это только в том случае, если аналитики смогли этот справочник корректно построить. (На эту тему у меня, кстати, есть статья).
2. Терминология "кирпичиков" для объектной модели компании как-то не очень подходит. Слишком упрощается представление.
3. Практически важно использовать несколько типов связей, а не только "является владельцем" и "выполняет процесс".
4. Совершенно не согласен, что "бумажные" документы не нужны. Наоборот, тем более в банке. Когда операционист фронт-офиса передает клиенту договор на открытие депозита, в какой он это форме делает? Правильно, в бумажной. И т.д. и т.п.
5. Рамка IDEF0 - совсем не нужна, имхо. Это пережитки времен г-на Кульмана. В системе есть вся информация про модель и историю ее изменения. Вне системы схемы легитимно могут существовать только в утвержденных регламентах (или их официальных проектах). В остальных случаях - это черновики бизнес-аналитика.
6. Выбор типа исполнителя "Подразделение" делается, имхо, только для того, чтобы потом показать в положении о подразделении перечень выполняемых процессов. Но не из-за того, что мы не знаем, кто отвечает за процессы внутри подразделения.
7. Прочие (много мелких вопросов).

Ещё раз подчеркну, что работа в статье проделана большая, за что Александру спасибо!

Коллеги, спасибо за внимание к материалу.
Выскажу мнение по поводу ряда замечаний.
- по поводу бумажных документов: а как быть тогда с электронной копией договора, которая циркулирует по информационным системам или со сканом того же договора? заводить еще один документ в справочнике? и если одна из форм документа измениться - означает ли это что измениться и другая форма документа? вообщем вопросов много.
- по поводу "Подразделения" простой пример. Юридическое управление проводит экспертизу сделки. Как мы можем знать наперед, ее будет делать начальник, ведущий специалист, или специалист. Кому писать этот функционал в должностную инструкцию? Поэтому и родилось решение - записать это на подразделение и при формировании инструкций - включить в ДИ каждому сотруднику, включая руководителя. Хочу подчеркнуть главное - это допустимо только для исполнителей. Владельцем всегда должен быть конкретный сотрудник. Если его выявить нельзя - в крайнем случае можно использовать роль (Экономист, ведущий кредитную сделку с клиентом).

1. По бумажным и электронным документам. Например, можно сделать так. Пока документ циркулирует в электронном виде, привязывать к стрелкам его. Как только он распечатывается (договор, накладная, счет и т.п.), то к стрелке привязывается бумажный документ под тем же названием. Можно пойти по другому пути. Сделать для электронного документа доп. атрибут "Распечатан/Не распечатан", например. В соответствующей операции процесса менять этот статус, если произошла распечатка документа.

2. Если в юр. отделе не знают, кто чем должен заниматься - печально ;-(

3. А мы наоборот делали - для операций процесса всегда должен быть исполнитель, а вот владелец процесса - это руководитель, отвечающий за результаты и эффективность процесса в целом. Он управляет исполнителями.

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

>>Хотим еще обратить внимание на интересную концепцию, которую использовали разработчики
программы - т.н. концепцию объектов стрелок. Простыми словами: мы можем назвать стрелку как
угодно, но в ее свойствах (невидимых на диаграмме) указать, что именно она означает.
Довольно странное замечание. Это основопогающий принцип SADT, который реализован и в BPWin. Только в отличие от него, в BS и список Объектов запонять удобно, и при работе с диаграммой можно посмотреть в любой момент состав объектов стрелки, просто наведя на нее мышкой и прочитав хинт.

Соглашусь с Дмитрием.
Но реалии жизни вынуждают делать все проще. Обычно в организации уходят месяцы на то, чтобы научить понимать графические диаграммы. А если еще окажется, что название стрелки не совсем означает ее суть - это тяжело. Поэтому в своей работе я использую простой принцип, если есть процесс, должен быть выходящий документ (это для банка). И документ нужно изображать. Если выходящего документа нет - то нет и процесса (за редким исключением).

А мне нравится в BS стрелки именовать так: "Подготовлен план продаж". К этой стрелке привязывать документ - "План продаж"...

Только это не по нотации. В SADT выходы - это сущности (объекты). Поэтому, то, что действие порождает событие, в нотациии IDEF0 не изображается и остается за кадром.