Подписаться
Рубрикатор
Полный список
Развитие организации
Управление процессами
Моделирование процессов
Регламентация процессов
Автоматизация процессов
Бережливое производство
Менеджмент качества
Управление проектами
Дайджесты по Business Studio

Облако терминов
12-процессная модель 4PL ACM Activity diagram AQPC ARIS ARIS 9 ARIS eEPC Balanced Scorecard Big Data & Analytic BMPN BPA BPEL BPM BPM accelerator BPM CBOK BPM-система BPM-системы BPMN BPMS BPR BPWin BS Portal BSC Business Intelligence Business Performance Management Business Performance Management (BPM) Business Process Management Business Process Management Systems Business Process Manager Business Rules Business Studio Business Studio 3.6 Business Studio 4 Business Studio 4.0 Business Studio Portal CA ERwin Data Modeler Case Management Casewise Casewise Corporate Modeler CFFC Corporate Modeler CPM CRM Decision Management DFD Digital Directum

Разработка архитектуры бизнес-процессов компании в Business Studio
Опрос

Вы используете

Библиотека

24.01.2011 20:16
  от автора
  Klimchuk_AA

Основные объекты программы. Как из них сложить модель процесса? (Статья 2 из цикла статей о цикла статей о Бизнес-Студии)

Оценки за материал: 4.67 (3)

Статья описывает наш опыт построения моделей бизнес-процессов деятельности банка в "Бизнес-Студии". Акцент сделан на сложных моментах работы программы и "подводных камнях". Приведены рекомендации по проверке модели с использованием матрицы ответственности и матрицы документооборота. Статья будет полезна практикам, занятым моделированием бизнес-процессов в банке и не только.
В приложении к статье приведены шаблоны описанных отчетов.
Статья 2. Основные объекты программы. Как из них сложить модель процесса?
Александр Климчук, к.т.н., доцент, начальник отдела бизнес-администрирования банка «Кредит-Днепр» (Украина)

Разноцветные панели инструментов и большие распахивающиеся меню: как из этого сделать полезную модель? Что использовать сразу, а что – потом? От чего стоит отказаться? Какой алгоритм разработки модели лучше?

2.1. Перед тем, как сесть за компьютер


Перед тем как начать строить модель бизнес-процессов банка задайте себе вопрос ЗАЧЕМ? Готов поспорить, что в большей половине случаев четкого ответа не последует. Автору часто приходилось слушать пространные рассуждения «… ну мы тут внедрим процессное управление …, я читал, что прописанные бизнес-процессы это хорошо …, у нас большие накладные расходы и бизнес-процессы их нам снизят … и т.п.». Главное правило: от того что мы просто нарисует бизнес-процесс ничего не измениться. Более того, после того, что мы нарисуем улучшенную модель бизнес-процесса – тоже ничего не измениться. Модель процесса – это всего лишь инструмент.
Как ни банально бы звучали рекомендации методики SADT4 [1], тем не менее – за все время существования процессного менеджмента не было предложено ничего лучшего. Эта методика предлагает перед началом моделирования определиться со следующим:
- Зачем создается модель бизнес-процесса (цель)?
- С какой позиции мы описываем бизнес-процесс (точка зрения)?
- Где начинается и где заканчивается моделируемый бизнес-процесс (охват)?

Ответы на эти вопросы крайне желательно формулировать перед началом моделирования
бизнес-процесса. Это избавит вас от потери времени на исправления модели. См. рис. 2.1.

Прикрепленные файлы

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

Комментарии

Оценки: /
24.01.2011 21:02
  от автора
  Yury.Radchenko
Для полноты изложенного материала, хотелось бы добавить, что по каждому типа процесса в Business Studio изначально есть отчет "Проверка правильности построения диаграммы... ".
Оно так же проверяет некоторую "орфографию" моделирования процесса.
Оценки: 1/
25.01.2011 10:32
  от автора
  Дмитрий Пинаев
>>Если
вы с помощью контекстного меню скопируете блок на диаграмме, а затем вставите его на этой
или другой диаграмме – вы создадите не новый подпроцесс, а всего лишь экземпляр
существующего процесса. При изменении одного экземпляра процесса будут меняться и прочие
экземпляры процесса. См. рис. 2.23.

Это не так, будет именно копия.
Оценки: 1/
25.01.2011 17:33
  от автора
  Репин
Привет, коллеги!

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

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

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

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

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


Оценки: 1/
25.01.2011 20:01
  от автора
  Klimchuk_AA
Коллеги, спасибо за внимание к материалу.
Выскажу мнение по поводу ряда замечаний.
- по поводу бумажных документов: а как быть тогда с электронной копией договора, которая циркулирует по информационным системам или со сканом того же договора? заводить еще один документ в справочнике? и если одна из форм документа измениться - означает ли это что измениться и другая форма документа? вообщем вопросов много.
- по поводу "Подразделения" простой пример. Юридическое управление проводит экспертизу сделки. Как мы можем знать наперед, ее будет делать начальник, ведущий специалист, или специалист. Кому писать этот функционал в должностную инструкцию? Поэтому и родилось решение - записать это на подразделение и при формировании инструкций - включить в ДИ каждому сотруднику, включая руководителя. Хочу подчеркнуть главное - это допустимо только для исполнителей. Владельцем всегда должен быть конкретный сотрудник. Если его выявить нельзя - в крайнем случае можно использовать роль (Экономист, ведущий кредитную сделку с клиентом).
Оценки: 1/
25.01.2011 21:44
  от автора
  Репин
1. По бумажным и электронным документам. Например, можно сделать так. Пока документ циркулирует в электронном виде, привязывать к стрелкам его. Как только он распечатывается (договор, накладная, счет и т.п.), то к стрелке привязывается бумажный документ под тем же названием. Можно пойти по другому пути. Сделать для электронного документа доп. атрибут "Распечатан/Не распечатан", например. В соответствующей операции процесса менять этот статус, если произошла распечатка документа.

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

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

Конечно, могут быть разные подходы к моделированию. Система мощная и дает простор для творчества. Поэтому любое решение, дающее практический результат, может считаться корректным.
Оценки: /
27.01.2011 15:40
  от автора
  Дмитрий Пинаев
>>Хотим еще обратить внимание на интересную концепцию, которую использовали разработчики
программы - т.н. концепцию объектов стрелок. Простыми словами: мы можем назвать стрелку как
угодно, но в ее свойствах (невидимых на диаграмме) указать, что именно она означает.
Довольно странное замечание. Это основопогающий принцип SADT, который реализован и в BPWin. Только в отличие от него, в BS и список Объектов запонять удобно, и при работе с диаграммой можно посмотреть в любой момент состав объектов стрелки, просто наведя на нее мышкой и прочитав хинт.
Оценки: /
31.01.2011 20:54
  от автора
  Klimchuk_AA
Соглашусь с Дмитрием.
Но реалии жизни вынуждают делать все проще. Обычно в организации уходят месяцы на то, чтобы научить понимать графические диаграммы. А если еще окажется, что название стрелки не совсем означает ее суть - это тяжело. Поэтому в своей работе я использую простой принцип, если есть процесс, должен быть выходящий документ (это для банка). И документ нужно изображать. Если выходящего документа нет - то нет и процесса (за редким исключением).
Оценки: /
04.02.2011 10:09
  от автора
  Репин
А мне нравится в BS стрелки именовать так: "Подготовлен план продаж". К этой стрелке привязывать документ - "План продаж"...
Оценки: /
11.02.2011 10:51
  от автора
  Дмитрий Пинаев
Только это не по нотации. В SADT выходы - это сущности (объекты). Поэтому, то, что действие порождает событие, в нотациии IDEF0 не изображается и остается за кадром.

Добавить комментарий

Комментировать материалы могут только зарегистрированные пользователи. Вы можете зарегистрироваться здесь.
©  2010-2014 В.В. Репин. Сайт основан 3 февраля 2001 г.

Все права защищены. Частичное или полное копирование информации данного ресурса возможно только с разрешения владельца.

Регистрация
О Портале
Правила
Контакты
Новости
Библиотека
Энциклопедия
Литература и сайты
Группы
Мои страницы
Тесты
Форум
Доска объявлений