Подписаться
Рубрикатор
Полный список
Развитие организации
Управление процессами
Моделирование процессов
Регламентация процессов
Автоматизация процессов
Бережливое производство
Менеджмент качества
Управление проектами
Дайджесты по 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
Опрос

Польза от регламентации процессов для бизнеса:

Библиотека

28.09.2012 14:17
  от автора
  Klimchuk Aleksandr

Студия процессов в банке: какой она должна быть?

Оценки за материал: 3.75 (4)

В последнее время нельзя не заметить маркетинговые усилия по продвижению программы «Бизнес-Студия», в частности – для банковской сферы. Специально для банков в дополнение к базовой версии программы разработан специальный шаблон, написаны книги по его внедрении, читаются семинары. Не снижая заслуг авторов, считаю свои долгом изложить ряд вопросов по использованию продукта в банке, которые остаются открытыми.
Маркетинг – маркетингом, но долговечность и востребованность продукта определяется его потребительскими свойствами. Поэтому крайне необходим «тест-драйв» программы «Бизнес-Студия» и методики, которая к ней прилагается.Провести такой анализ мне позволяет длительное знакомство с продуктом и полуторалетний опыт его использования непосредственно в банке («Кредит-Днепр», г. Киев)

Свои выводы по итогам практической работы с продуктом я структурировал в виде ответов на три вопроса: «Зачем?»,«Как?» и « Где?» применять «Бизнес-Студию» в банке.
1. НАЧНЕМ С ГЛАВНОГО ВОПРОСА: ЗАЧЕМ?

Первым приходит в голову простой ответ – для внедрения процессного управления. Но если отбросить в сторону рассуждения о перспективности данного подхода, доводы, «что все это уже делают» - то в чем же смысл?

А смысл очень простой - повышение эффективности банка, как машины для зарабатывания денег. Сначала мы пытаемся взять под контроль основные сквозные процессы, затем добавляем к ним показатели, проводим мониторинг и внедряем проекты по оптимизации. После этого – смотрим на вспомогательные процессы, например – управление персоналом, развитие ИТ-инфраструктуры и т.п.

С перечисленными аргументами трудно спорить. Но где тут место для «Бизнес-Студии», как она может повлиять на работу банка?

2. КАК ИСПОЛЬЗОВАНИЕ БИЗНЕС-СТУДИИ МЕНЯЕТ РАБОТУ БАНКА?

Лично мое мнение – название «Бизнес-студия» было подобрано неудачно. Оно созвучно с творчеством, поиском решений, неким хаосом из которого может быть взойдет что-то рациональное. Но бизнес- это всегда машина, машина для зарабатывания денег. А банка – это еще и консервативная, точная машина.

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

Даже если и предположить, что процессная модель в бизнес-студии может стать основой для написания технического задания – то набор стандартов в продукте явно не самым удобным. Хотя я и сам фанат элегантности стандарта IDEF0, но следует признаться – для ТЗ лучше чем стандарт BPMN не придумано. Не вдаваясь в детали, укажу лишь главную причину – этот стандарт позволяет описывать несинхронные процессы, в то время как бизнес-студия «заточена» лишь на синхронные.

Вот и получается на практике: подразделение – «студия» бизнес-процессов рисует свои схемы процессов, а ИТ- службы потом под себя делают другие модели. А то и вообще пишут описание требований в текстовом и табличном редакторе. Со стороны ИТ специалистов возникает резонный вопрос: зачем дважды делать ту же самую работу? Появляется «зоопарк» бизнес-процессов.

У «Бизнес-Студии» в арсенале есть еще аргумент в пользу ее практической полезности – это возможность автоматически перейти от процессного описания деятельности организации к положениям о подразделениях и должностным инструкциям. Но и тут не все гладко.

На практике добиться автоматического формирования данных структурных документов крайне сложно. По двум причинам:
• Несогласованные справочники.
• Отсутствие описания всех процессов.

Под несогласованностью справочником я имею ввиду следующее. Как наиболее правильно и удобно формировать модель бизнес-процессов в бизнес-студии? Используя как кирпичики элементы справочников: должностей, документов, ИТ систем, KPI и т.п. А кто даст гарантию, что они актуальны? Даже однажды погрузившись в «зоопарк» ИТ – систем банка, выудив оттуда все необходимые справочники, вычистив их «от мусора» и залив в бизнес-студию мы ни в коем случае не будет уверены, что обеспечили синхронность этих справочников на следующем шаге. В банке появляется новая должность: каким образом ее название отразиться в справочнике бизнес-студии, она будет назначена как участник бизнес-процессов и пр.? Но это еще не главная трудность.

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

3. ГДЕ ЖЕ МЕСТО БИЗНЕС-СТУДИИ В БАНКЕ?

Подходим к главному вопросу: где же будет полезно использование бизнес-студии в банке?

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

Классически, в архитектуре процессного управления выделяют три уровня:
1. Концептуальный, описание бизнес-модели.
2. Описание сквозных процессов, когда от концепции мы переходим к сквозной спице, которая проходит через всю организацию и на которую как на шампур мы пытаемся нанизать функции с их атрибутами (исполнители, время, документы и пр.)
3. Описание функционала для рядовых исполнителей, которые может и не догадываются о всей грандиозности сквозного процесса, им важно лишь описание действий, которые нужно осуществить.

У уровней разные участники и, следовательно, разные требования к процессной модели. Где наиболее уместно использование бизнес-студии?
На концептуальном уровне тут важна простота и понятность схемы. Для этого достаточно и пауэр-поинта, максимум – визио. Делать эту работу в бизнес-студии не очень удобно из-за диссонанса концептуальности рисунка и необходимости использовать существующие справочники-классификаторы модели.

Описание сквозных процессов. Тут скорее да, чем нет. Но есть ограничения. О них я писал выше.

На уровне рядовых исполнителей используется два основных документа: положение о подразделении и должностная инструкция. Естественно хочется использовать встроенные в программу возможности по автоматическому формированию данных документов. Но на практике это сделать сложно. Редко можно добиться полной базы данных процессов. А если база не полная – то и в документах будет лишь часть необходимой информации. Придется дополнятьвручную, параллельно вычищая текст от неактуальных сведений.

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

ВЫВОДЫ
1. Продукт «Бизнес-Студия» необходим банку как инструмент повышения эффективности деятельности, а не в роли творческой студии.
2. Повлиять на деятельность банка можно: 1. Изменив настройки программного обеспечения. 2. Переписав должностные инструкции или положения о подразделениях. Графические диаграммы могут понять лишь «избранные» сотрудники банка.
3. Формирование технических заданий на автоматизацию бизнес-процессов и автоматизация разработки структурных документов сопряжено с рядом вопросов, ответы на которые не просты и не однозначны.
4. Начинать внедрение «Бизнес-Студии» в банке без ответов на данные вопросы не следует. Проект потеряет свою эффективность.

Александр Климчук, начальник управления организационного развития банка «Кредит-Днепр» (г. Киев), к.т.н., a.klimchuk@gmail.com

Комментарии

Оценки: /
28.09.2012 15:15
  от автора
  Yury.Radchenko
На уровне рядовых исполнителей используется два основных документа: положение о подразделении и должностная инструкция. Естественно хочется использовать встроенные в программу возможности по автоматическому формированию данных документов. Но на практике это сделать сложно. Редко можно добиться полной базы данных процессов. А если база не полная – то и в документах будет лишь часть необходимой информации. Придется дополнятьвручную, параллельно вычищая текст от неактуальных сведений.

В отчет, например "Должностная", можно брать как процессы, так и обычный вольный текст вида "... и выполняет другие поручения руководителя".
Стандартное решение в БС. Детали описаны здесь http://mymanager.com.ua/bp/bs/bshacker/detal.php?ID=17362

Придется дополнятьвручную, параллельно вычищая текст от неактуальных сведений.

Какой именно текст удалять? Зачем заносить неактуальные сведения, чтобы потом их удалять?
Оценки: /
28.09.2012 17:16
  от автора
  Петров Дмитрий
Странно видеть столь негативную статью на дружественном БС портале.

Основные тезисы автора:
1) Техническое задание в БС писать неудобно, лучше в BPMN;
2) Пользоваться функциями по генерации должностных инструкций и положений для банка затруднительно из-за неполноты модели, т.к. не до всех процессов доходят руки;
3) Для описания концептуального уровня процессной модели лучше воспользоваться PowerPoint или Visio.
4) Использование веб-навигатора затруднительно из-за отсутствия возможности распределять доступ;
5) Можно попробовать описать сквозные процессы в БС и то с определенными ограничениями;

Лично у меня возникло такое ощущение, что кто-то на высшем уровне сначала принял решение купить программный продукт, а лишь потом задумался, а как же его использовать
Оценки: /
28.09.2012 17:59
  от автора
  Klimchuk Aleksandr
Дмитрий, добрый день.
К счастью - данный портал несет в себе не маркетинговую цель продавать. Его цель – развивать процессное управление. В этом - основа его популярности.
Про то, как хороша программа – всегда вы можете прочесть на сайте разработчика 
Мы не на сейте фанатов футбольной команды, поэтому предлагаю перейти от категорий "нравиться" или "не нравиться" продукт, к категориям «может» и «не может» решать управленческие задачи. В данном случае – в материале я поднял четкие задачи, на которые ответов у меня нет.
Если вы решили их у себя в организации - расскажите об этом успешном примере. Мы будем вам благодарны и возьмем опыт на вооружение.
Оценки: /
28.09.2012 18:11
  от автора
  Klimchuk Aleksandr
Юрию:

Мой тезис прост: я не встречал на практике случаев внедрения "Бизнес-Студии", когда структурные документы формировались автоматически (хотя бы большая их часть).
Добиться ситуации, когда все процессы описаны, под них подвязаны все должности, в актуальном состоянии поддерживаются справочники документов и пр.
Тут дело не в том: может или нет ПО технически. Вопрос - управленческий и организационный.
Оценки: /
28.09.2012 21:11
  от автора
  Петров Дмитрий
я не встречал на практике случаев внедрения "Бизнес-Студии", когда структурные документы формировались автоматически (хотя бы большая их часть.

В случае с программой Fox Manager, такие примеры имеются, уверен, и у Business Studio они есть. Просто у банков своя специфика работы. Многие процессы полностью автоматизированы, поэтому смысла их описывать в системе бизнес-моделирования нет. Отсюда неполная процессная модель, проблемы при генерации должностных инструкций и положений о подразделении и т.д. Зато у банков почти всегда есть бюджеты на развитие ИТ, вот на них и нацеливаются разработчики.

Но это всё всего лишь моё личное мнение…
Оценки: /
28.09.2012 22:48
  от автора
  Yury.Radchenko

Тут дело не в том: может или нет ПО технически. Вопрос - управленческий и организационный.

Может тогда лучше говорить о границах всех программ данного класса? Причем тут только Business Studio?


я не встречал на практике случаев внедрения "Бизнес-Студии", когда структурные документы формировались автоматически (хотя бы большая их часть.

Предлагаю бывать гостем на вебинарах, проводимых разработчиком Business Studio. Там проводятся встречи с реальными пользователями, которые рассказывать что они делают с БС, какие отчеты формируют. В прямом эфире можете задать пользователям свои вопросы.
Есть записи таких вебинаров.
Оценки: /
28.09.2012 23:41
  от автора
  Репин
"...Что есть результатом использования этого продукта? Ответ один - это регламентирующие документы. А чем в большинстве регулируется работа банка? Настройкой программных комплексов. Если что-то где-то и не охвачено автоматизацией – то это либо второстепенные функции..."
Да, выгрузка регламентов - одно из сильных сторон BS. Но ответ "не один". Командная работа над описанием, анализом и оптимизацией процессов может дать эффект. В любом банке есть процессы управления, которые не автоматизированы. Но от них зависят результаты бизнеса.

"... в то время как бизнес-студия «заточена» лишь на синхронные..."
Александр, просьба пояснить этот тезис. Синхронность и асинхронность может быть отображена при корректном использовании объектов типа "Событие".

"...На практике добиться автоматического формирования данных структурных документов крайне сложно. По двум причинам:
• Несогласованные справочники.
• Отсутствие описания всех процессов..."

С этим согласен. Но кто мешает описать целиком процессы отдела, а потом выгрузить положение о подразделении? Далее по частям всю систему...

"...Готов поспорить – что у авторов продукта нет ни одного примера, когда все организация была описана в продукте и модель поддерживалась в актуальном состоянии..."

Александр, это общая проблема при использовании любых средств моделирования бизнес-процессов:ARIS, Casewise и т.п.

В целом, в статье затронуты проблемы, характерные для использования среды моделирования процессов. Нет каких-то специфических особенностей Business Studio (за исключением ограниченного количества нотаций).

Поэтому, было бы полезно обсудить практику решения именно общих, системных проблем применения среды моделирования в организации.
Оценки: /
02.10.2012 09:22
  от автора
  Klimchuk Aleksandr
Дмитрию:
"Многие процессы полностью автоматизированы, поэтому смысла их описывать в системе бизнес-моделирования нет. Отсюда неполная процессная модель," - категорически не согласен!!!
Как раз неэффективность процессов, автоматизированных в ПО есть первая причина неэффективности банка.
Традиционно сложилось, что ИТ специалисты являются одними из самых консервативных с точки зрения развития бизнеса, удовлетворенности клиентов, получения прибыли ... Поэтому по своей воле они ничего апгрейдить не будут. Нужен "пинок" сверху. Или ответьте на простой вопрос: есть ли в вашей организации актуальные описания всех программных комплексов? (т.е. описание процессов, "зашитых в них"). Готов поспорить - что всех нет. Вписок аргументов против вашего тезиса могу продолжать.
Как раз наоборот, те процессы, которые можно поменять управленческим решением (а не ждать месяцами исполнения заявки на доработку ПО) - являются наиболее адаптируемыми в организации.
Оценки: /
02.10.2012 09:23
  от автора
  Klimchuk Aleksandr
Юрию:
Спорить не буду Естественно, есть приятные исключения из правил.
Оценки: /
02.10.2012 09:34
  от автора
  Klimchuk Aleksandr
Владимиру:
Про командную работу - согласен на 100% Но так сложилось, что мы для этого используем чаще Mind Map, поэтому в материале акцент и не сделал на данной функции.
Про "синхронность" - например, есть производственное подразделение. Допустим для простоты, в нем есть два процесса: планирование и производство. Вопрос: как их корректно описать на верхнем уровне?
Обычно рисуем два блока: сначала планируем, потом производим, причем из первого блока во второй поступает управленческое воздействие "план". Но ведь так в жизни не происходит. Каждую минуту происходит и планирование и производство. План постоянно подстраивается под новые заявки, под проблемы с поставками и пр. Условно это можно представать как два колеса, которые вращаются с разной скоростью ...
Про подразделения - согласен.
Про системные проблемы - согласен.
Оценки: /
02.10.2012 10:33
  от автора
  Репин
Александр,
при описании на верхнем уровне я бы предложил использовать "Управление производством" и "Производство продукции"... Привожу пример структуры процессов производства:

5. Производство продукции
5.1. Оперативное управление производством
5.1.1. Разработка и согласование плана производства на месяц
5.1.2. Формирование графика производства ... продукции на месяц
5.1.3. Формирование заявок на сырье, закладные детали, упаковочные материалы
5.1.4. Еженедельная корректировка графика производства ... продукции
5.1.5. Еженедельная корректировка плана и графика производства ... продукции с дополнительными заданиями невключёнными в план месяца
5.1.6. Ежедневное формирование и выдача сменного задания по технологическим линиям на производство ... материалов и изделий, учёт произведённой продукции
5.1.7. Передача смены мастерами
5.1.8. Ежедневная выборочная инвентаризация сырья и ГП в зоне производства
5.1.9. Формирование заказа на востановление существующих форм
5.1.10. Предъявление продукции на паспортизацию, сдача готовой продукции на склад
5.1.11. Состовление отчётов по ... продукции за месяц
5.1.12. Состовление актов на списание материалов, инструментов, инвентаря за месяц
5.2. Получение со склада, хранение и перемещение сырья на производстве
5.2.1. Получение со склада необходимого сырья, упаковочных материалов на основаниии "загрузочных таблиц"
5.2.2. Хранение сырья и упаковочных материалов в зоне производства (определённое место возле линий)
5.2.3. Хранение остатков сырья, премиксов
5.2.4. Перемещение сырья от места временного хранения к линии
5.2.5. Учет внутренних перемещений сырья
5.3. Производство ... на линии ,..
5.3.1. Анализ "загрузочной таблицы" и определение потребности в сырье
5.3.2. Ввод новой программы на пульте управления линии ...
5.3.3. Ввод программы на пульте управления линии ...
5.3.4. Загрузка бункеров линии ... по "загрузочным таблицам"
5.3.5. Дозировка "ручные добавки" сырья в ёмкость серволифта согласно рецептурной карте
5.3.6. Контроль выполнения замеса на линии ...
5.3.7. Заполнения протокола ручных добавок
5.3.8. Упаковка продукции согласно сменному заданию
5.3.9. Перемещение готовой продукции на склад
...
...
...

Далее процессы увязываются по событиям и информационным входам/выходам.
Оценки: /
02.10.2012 18:06
  от автора
  Петров Дмитрий

Как раз неэффективность процессов, автоматизированных в ПО есть первая причина неэффективности банка.

Зачем описывать процессы? Наверное, чтобы их оптимизировать. Ну, допустим, есть процесс формирования выписки в банк-клиенте или обработка платежных поручений. Процесс полностью автоматизирован. Вы, конечно, можете описывать подобные процессы в системе бизнес-моделирования, но оптимизировать их не удастся без внедрения нового программного обеспечения, в котором, в свою очередь будут свои жестко-прописанные бизнес-процессы.
Вот если бы речь шла об автоматизированных процессах, которые построены в какой-то системе управления бизнес-процессами, например, в формате BPMN…
Оценки: /
02.10.2012 18:10
  от автора
  Петров Дмитрий
Про "синхронность" - например, есть производственное подразделение. Допустим для простоты, в нем есть два процесса: планирование и производство. Вопрос: как их корректно описать на верхнем уровне?
Обычно рисуем два блока: сначала планируем, потом производим, причем из первого блока во второй поступает управленческое воздействие "план". Но ведь так в жизни не происходит. Каждую минуту происходит и планирование и производство. План постоянно подстраивается под новые заявки, под проблемы с поставками и пр. Условно это можно представать как два колеса, которые вращаются с разной скоростью ...

IDEF0 позволяет отобразить лишь логические связи между работами, а не их временную последовательность.
Оценки: /
03.10.2012 16:07
  от автора
  Klimchuk Aleksandr
Дмитрию:
"... в котором, в свою очередь будут свои жестко-прописанные бизнес-процессы ..." - да есть. Такой класс продуктов называется "операционный день банка".
Но вопрос же не в этом. Конкурентные преимущества банка как раз и формируются инвариантными составляющими бизнес-процессов, а не внутренней кухней бэк-офиса.
Например, сколько документов клиент вынужден заполнять и подписывать, пользуясь продуктами и услугами банка, сколько раз он вынужден ту же самую информацию сообщать различным сотрудникам, насколько он осведомлён о прохождении своей заявки на кредит и как быстро она обслуживается ... и так далее.
Послушать программистов - так у них все "жестко зашито", и это понятно. Если жестко зашито - то зачем и напрягаться, адаптируя процессы под клиентов
Про IDEF 0 - согласен на 100%. Мой тезис - для асинхронности нужно использовать BPMN.
Оценки: /
03.10.2012 16:08
  от автора
  Klimchuk Aleksandr
Владимиру:
Да. Можно и так
Оценки: 1/
15.10.2012 10:15
  от автора
  Aleksandra Kudryavtseva
Александр, кажется, что, несмотря на какой-то опыт работы с BS и аналогичными программными средствами, Вы все же не совсем "разглядели" всех возможностей этих систем. Или сделали скорополительные выводы
Ведь и "простота и понятность" (как на концептуальном, так и на всех других уровнях)обеспечена МОЖЕТ быть (пусть даже с использованием некоторых элементов визуализациипри из VISIO). Графические модели (при тщательно продуманном и грамотно составленном соглашении о моделировании)становятся понятными ВСЕМ сотрудникам (разумеется, с высшим образованием . Описывать ВСЕ процессы для генерации регламентирующих документов совсем не обязательно - достаточно описать проблемные, неформализованные. И работу ИТ-служб надо бы организовать не как "дублирование" работы бизнес-аналитиков, а как ее продолжение (для подготовки к автоматизации необходим другой взгляд на процесс и использование других объектов). А хранение ВСЕЙ информации на разных уровнях детализации в ЕДИНОЙ "процессной" базе данных - совершенно необходимо (и никакие VISIO тут не работают).
Приходите к нам - в "Альфа-Банк Украина". И сгенерированные положения покажем, и синхронизацию справочников обсудим, и о ФСА поговорим (этим инструментом Вы, похоже, не пользуетесь вовсе).

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

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

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

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