|
|
Рубрикатор |
|
|
Облако терминов |
|
|
Опрос |
|
|
|
|
|
Библиотека |
|
03.03.2014 23:52 |
|
от автора
Система моделирования бизнес-процессов: возможности, влияющие на эффективность практического применения
Оценки за материал: 5.00 (2)
В статье В.В. Репина рассматриваются функциональные возможности систем моделирования бизнес-процессов, которые могут существенно повлиять на эффективность их практического применения в ближайшем будущем. Автор приглашает к диалогу как пользователей систем (бизнес-аналитики, менеджеры по развитию), так и потенциальных клиентов.
Для чего нужна система моделирования?
В статье речь пойдет о программных продуктах определенного класса – системах моделирования бизнес-процессов (ARIS, Casewise, iGrafx, Business Studio и др.). С точки зрения автора статьи, такие системы могут быть весьма полезны при создании базы знаний компании, основанной на процессном взгляде на деятельность. Эти системы позволяют:
- создавать комплексные, многоуровневые модели бизнес-процессов, организационной структуры, документов, целей и показателей, которые могут, в первую очередь, быть использованы для оптимизации (реинжиниринга) бизнес-процессов и орг. структуры организации;
- накапливать информацию в контексте процессов (результаты внутренних аудитов, выполнения корректирующих и предупреждающих действий, проектов оптимизации; информации по бенчмаркингу и проч.);
- генерировать для персонала компании информацию регламентирующего характера (регламенты, инструкции, положения и т.п.) в форме документов MS Word или в виде страниц на web-портале;
- выполнять имитационное моделирование бизнес-процессов с целью поиска направлений их оптимизации;
- частично поддерживать деятельность по оперативному управлению (ввод/вывод плановых и фактических значений показателей, в т.ч. с использование web-портала);
- разрабатывать технические задания для автоматизации бизнес-процессов (например, путем создания моделей в нотации BPMN).
В настоящее время наблюдается активное развитие систем моделирования. На мой взгляд, существует ряд аспектов, которые могут существенно повлиять на эффективность практического применения систем моделирования в ближайшем будущем. Рассмотрим их последовательно.
1. Регламент без регламента
Практически все руководители компаний в той или иной степени убеждены в необходимости регламентации деятельности своих сотрудников. При достижении определенного уровня зрелости компания не может без них обойтись. Однако как только в организации появляется значительное число регламентирующих документов, возникает ситуация, когда эти документы:
- своевременно не обновляются;
- противоречат друг друг;
- частично дублируют друг друга;
- и т.п.
С точки зрения сотрудников, использующих регламенты, проблема выглядит так:
- нет времени читать «толстые» регламенты;
- сложно находить нужную информацию в большом количестве документов;
- долго и сложно вносить изменения в связанные между собой нормативные документы;
- прочие.
Таким образом, налицо конфликт между необходимостью регламентировать деятельность и сложностью практического использования нормативных документов. В рамках стандартного, общепринятого взгляда этот конфликт является неразрешимым. Поэтому многие консультанты ищут ответ в использовании других методов, в первую очередь в автоматизации бизнес-процессов. Однако автоматизация, к сожалению, по разным причинам не устраняет данный конфликт в полной мере (не все процессы можно автоматизировать и т.д.). Нужно искать решение в другой плоскости.
Именно в этой связи стоит сказать про первый функциональный аспект среды моделирования бизнес-процессов, который данный конфликт практически устраняет. Он может быть сформулирован следующим образом:
Полный отказ от регламентирующих документов в традиционном смысле (бумага, файлы MS Word или pdf). Информация, опубликованная со статусом «Утверждено» на внутреннем web-портале компании, заменяет собой регламенты, т.е. является обязательной к исполнению.
Что это означает? Среда моделирования используется в качестве базы знаний по бизнес-процессам. После внесения изменений в модель процесса (орг. структуры, документов и т.п.), информация становится доступной на портале со статусом «На согласовании». Web-портал (тесно интегрированный или непосредственно являющийся модулем среды моделирования) позволяет осуществлять согласование и утверждение изменений в электронном виде (в т.ч. с использование ЭЦП). Кроме того, система дает возможность:
- визуализировать последние изменения (например, выделять цветом на схемах те операции процесса, требования к которым были изменены);
уведомлять пользователей по e-mail;
- визуализировать изменения различного в виде иконок (как, например, сделано на facebook);
- автоматически генерировать список всех изменений с гиперссылками на нужные разделы регламентов, которые касаются именно данного сотрудника;
прочие.
Таким образом, скорость внесения изменений в массив регламентирующей информации радикально изменяется. С учетом наличия таких устройств, как планшеты, у всех сотрудников появляется быстрый и легкий способ доступа к нужной именно ему информации.
2. Простота моделирования
Второй аспект работы со средой моделирования – это простота. Для работы нужна простая, но выразительная нотация описания процессов. Но что мы имеем на сегодняшний день? CFFC (Cross Functional Flow Chart) – диаграмма с «ромбиками», eEPC и BPMN. Последняя нотация – самая сложная. Некоторые считают, что ее может использовать любой сотрудник компании, если ограничить количество применяемых элементов (т.е. фактически создать т.н. «методический фильтр», как это в свое время делали консультанты при внедрении ARIS). Но на практике довольно сложно обучить большое количество людей в компании корректно использовать BPMN. Итак, нужна нотация, которая была бы простой и понятной «с первого взгляда» обычного человека, но в то же время достаточно выразительной для целей описания реального бизнес-процесса.
Есть еще одна проблема, но в другой плоскости. Удобно ли отображать информационные потоки на диаграмме BPMN? Скорее «нет», чем «да». А если нужно будет изобразить другую информацию, например материальные потоки? В свое время ARIS предлагал решать такого рода проблему путем создания множества моделей разного типа, описывающих один и тот же процесс. Сложно назвать такой подход удобным для пользователя.
Думаю, что в перспективной системе бизнес-моделирования должны быть реализованы «многослойные» модели. Т.е. модель будет одна, но можно будет переключаться между слоями, меняя визуальное представление. Хотим видеть на схеме потоки управления – включаем слой «Work Flow/Control Flow». Хотим видеть потоки данных и хранилища – включаем слой «Data Flow» и т.п. Почему при бизнес-моделировании до сих пор нет возможности делать слои, как в P-CAD или Photo Shop?!
Далее. Очень бы хотелось уйти от необходимости разрабатывать отчеты для вывода информации из системы путем сложных настроек, требующих хороших знаний структуры данных модели, программирования на каких-то языках и т.п. Нужна возможность простого визуального проектирования отчета по принципу «взял нужный атрибут со схемы (из описания объекта) и перетащил в шаблон отчета». Система должна сама определять нужную структуру запроса к базе данных. Слишком уж сложно сейчас проектировать отчеты для пользователей, если их потребности выходят за рамки простейших и банальных требований. В этой связи хочется добавить еще возможность простого визуального расширения структуры данных модели без необходимости глубокого владения системными командами и т.п.
3. Все в web
Современная система моделирования процессов, на мой взгляд, должна работать через web-броузер, т.е. не иметь каких-либо десктопных приложений (за исключением сервера базы данных и служебных приложений для администраторов). Таким образом, работа будет осуществляться прямо в броузере – графические схемы, справочники процессов, орг. структура, документы и проч. При этом должна существовать возможность фильтровать информацию по статусам моделей (например «Для публикации»). Кроме того, обязательно должна быть реализована возможность использовать ЭЦП для согласования и утверждения моделей процессов.
Следует особенно подчеркнуть важность такого параметра системы, как скорость работы. При использовании web-портала информация должна обновляться практически мгновенно. Страницы со схемами процессов и документами должны открываться очень быстро. Иначе пользователи просто не захотят пользоваться справочной и регламентирующей информацией из системы. Не должно быть таких ситуаций, когда процесс обновления информации из базы на web-портале загружает сервер на много часов, если не суток.
Работа на web-портале среды моделирования даст возможность измерять активность пользователей, анализировать, какая информация пользуется спросом, а какая нет. Таким образом, легко будет рассчитать ряд показателей, по которым можно управлять системой описания и регламентации бизнес-процессов компании, планомерно повышая ее эффективность.
Еще одной особенностью должна стать возможность гибкой настройки интерфейса системы под свои задачи. Пользователь должен иметь комфортное информационное пространство для работы, а не жесткое меню, построенное в логике разработчика системы и понятное только ему.
4. Процесс без графической схемы
«Процесс может быть любым при условии, что это графическая схема» - это перефразированный девиз Генри Форда про черный автомобиль. Почему-то при моделировании организации во многих системах (кроме iGrafx) схему бизнес-процесса принято считать самим бизнес-процессом. Но это не так. Модель процесса не тождественна его графической схеме. Процесс - это более сложный объект для управления. Поэтому в современной среде бизнес-моделирования процессы должны выступать как объекты, с которыми можно связать информацию различного характера, в том числе несколько графических схем бизнес-процессов. В качестве примера можно привести систему моделирования iGrafx, в которой такое идеологическое разделение процесса и графической схемы реализовано вполне четко. В системе создается справочник процессов, причем каждый процесс является объектом. К такому объекту может быть привязано неограниченное количество любых других сущностей, определенных в системе, в т.ч. различных графических схем. На мой взгляд, такое решение позволяет создавать весьма интересные и практически полезные методические решения при внедрении процессного управления.
5. Поддержка оперативного управления
Оперативное управление процессами предполагает планирование и контроль деятельности по определенным показателям. Система моделирования будет гораздо более востребованной практически, если обеспечит возможность интеграции с учетными системами и возможность ввода/вывода плановых и фактических значений показателей. Обязательно должна быть возможность быстрой и легкой настройки панелей управления с интерактивными графиками и диаграммами, которые необходимы руководителю для управления процессом. Конечно, в данном случае налицо пересечение функциональных возможностей системы с BI/BPM (Business Performance Management). Поэтому, видимо, необходима интеграция с такими системами, но обязательно в удобной пользователю форме и через web-интерфейс.
6. Прочие
Среди прочих, не таких значительных аспектов перспективной системы бизнес-моделирования, можно упомянуть следующие:
- легкость перехода с версии на версию;
- отсутствие глюков (багов);
- цена решения (не более 3 тыс. рублей за одно рабочее место).
Процессное управление «пойдет в массы» только при наличии простого, удобного, эффективного и дешевого программного инструмента.
Резюме
Приглашаю к дискуссии. Уверен, что практикующие бизнес-аналитики предложат еще десяток-два аспектов, которые являются для них критичными. Собственно, статья и была написана для того, чтобы обсудить различные взгляды на требования к перспективной системе моделирования бизнес-процессов.
В.В. Репин,
к.т.н., Исполнительный директор и партнер ООО «BPM Консалтинг Групп»,
доцент кафедры Бизнес-информатики и систем управления производством Национального Исследовательского Технологического Университета.
Март 2014 г.
Комментарии
Оценки:
/
|
04.03.2014 12:15 |
|
от автора
С тезисами статьи согласен. Но считаю систему моделирования - пол-шажком в сторону систем управления бизнес-процессами. Регламент и реальное выполнение бизнес-процесса - это разное.
Оценки:
/
|
04.03.2014 12:19 |
|
от автора
В продолжение статьи хочу поднять для обсуждение вопрос: если нужно изменить регламент, должностную инструкцию, процедуру и пр. - в каких случаях это лучше делать через изменение модели, а в каких - просто внести правки в документ. В смысле - соотношение "красоты работы" и "эффективности работы". Я сам часто грешу, когда не хвататет времени - вношу просто изменения в документы.
Оценки:
/
|
04.03.2014 12:41 |
|
от автора
На мой взгляд, это зависит от корпоративной культуры компании. В какой-то момент развития становится понятно, что содержание огромного количества бумажных документов дорого и неэффективно. Многие из них связаны между собой. Внесение изменений в связанный массив документов осуществлять сложно. А при ручных доработках ситуация усугубляется. Именно поэтому, на мой взгляд, целесообразно использовать модель с выгрузкой в web.
Оценки:
/
|
04.03.2014 13:34 |
|
от автора
Цитата1:
В свое время ARIS предлагал решать такого рода проблему путем создания множества моделей разного типа, описывающих один и тот же процесс. Сложно назвать такой подход удобным для пользователя.
Цитата2:
В качестве примера можно привести систему моделирования iGrafx, в которой такое идеологическое разделение процесса и графической схемы реализовано вполне четко. В системе создается справочник процессов, причем каждый процесс является объектом. К такому объекту может быть привязано неограниченное количество любых других сущностей, определенных в системе, в т.ч. различных графических схем. На мой взгляд, такое решение позволяет создавать весьма интересные и практически полезные методические решения при внедрении процессного управления.
Так на какой же позиции стоит автор?
Оценки:
/
|
04.03.2014 13:39 |
|
от автора
Термин "система моделирования бизнес-процессов" я бы не использовал, т.к. он уводит мысли людей в сторону. Как произошло с Александром, например:
"Но считаю систему моделирования - пол-шажком в сторону систем управления бизнес-процессами. Регламент и реальное выполнение бизнес-процесса - это разное. "
Я бы использовал термин "система для проектирования бизнес-архитектуры" и понимал бы под ним систему для разработки набора моделей необходимых для описания или проектирования всей бизнес-системы, в которой вообще говоря, есть много чего еще, кроме бизнес-процессов.
Оценки:
/
|
04.03.2014 16:30 |
|
от автора
В ARISe не было понимания процесса, как объекта, к которому можно привязывать различные другие сложные объекты (схемы и проч.). Просто была возможность создавать набор моделей в разных нотациях. В iGrafx так делать можно. Можно, например, привязать к одному процессу несколько схем в разных нотациях...
Оценки:
/
|
04.03.2014 18:02 |
|
от автора
Интересная дилемма - с одной стороны, наличие регламента нужно для формальной стороны дела (как закон: нарушил явно указанное - виноват, не нарушил или не указано - не виноват), но куча регламентов, как справедливо отмечено в статье, становится неподъёмной ношей в части их изучения участниками процесса, актуализации и взаимной гармонизации. С другой, база знаний без чёткой "бумажной" регламентации даёт бОльшую свободу и удобство, но может вызвать коллизии - постоянно в БЗ смотреть не будешь (особенно для процессов, не подлежащих полной автоматизации), и можно не заметить момент актуализации (даже если есть уведомления об изменении, всё равно в таком потоке, при определённой его плотности, легко захлебнуться).
Оценки:
/
|
04.03.2014 19:24 |
|
от автора
Ну можно настроить РС так, чтобы при включении сразу загружался броузер с порталом, на котором эти обновления видны...
А лучше, конечно, чтобы у сотрудника была зайти внутренняя мотивация самому зайти на портал утром, как например на facebook Это значит, что в БЗ должна быть актуальная и полезная информация.
Оценки:
/
|
04.03.2014 23:23 |
|
от автора
Вот тут ловушка. Не все бизнес-процессы выполняются за компьютером, так что исполнитель может и не заглянуть в портал (особенно, если процесс уже отработан до автоматизма), а если и выполняются за компьютером - то тогда возникнет проблема интеграции рабочего инструмента (CRM, ERP и т.п.) и портала на предмет "перепроверки" актуальности процесса.
Оценки:
/
|
04.03.2014 23:32 |
|
от автора
Процессы, которые выполняются за компьютером можно автоматизировать. Но многие процессы, которые реально выполняются (например мобилизация бригады или собственно проведение подземного ремонта скважины) выполняются физически, по определенной технологии и с использованием определенного оборудования. Т.е. процесс есть, а автоматизация почти нет. Но сотрудниками выполняющим такую работу периодически приходится заглядывать в тех. регламенты. БЗ в этом случае существенно бы упростила, ускорила доступ к нужной информации.
Что касается актуальности процесса, не совсем понял, что имеется в виду? Фактические значения показателей процесса?
Оценки:
/
|
05.03.2014 00:16 |
|
от автора
Актуальность - я имею в виду те аспекты БП, которые должны отражаться в регламенте при изменении этого регламента. Т.е. состав действий, последовательность, состав участников, передача управления/исполнения, распределение ответственности, порядок учёта, отчётность и т.п.
Оценки:
/
|
05.03.2014 10:01 |
|
от автора
Согласен. Правильно ли я понимаю, что Вы говорили о необходимости актуализировать регламенты при изменении порядка работы с информационными системами (CRM, ERP)?
В любом случае, БЗ будет работать эффективно только при наличии четких методик ее поддержки и адекватного человеческого ресурса. На мой взгляд, затраты на ее содержание будут существенно меньше, чем величина потерь, которые будут устранены при ее использовании.
Оценки:
/
|
05.03.2014 12:49 |
|
от автора
Правильно ли я понимаю, что Вы говорили о необходимости актуализировать регламенты при изменении порядка работы с информационными системами (CRM, ERP)?
Не только. Любое изменение любого процесса, с чем бы оно ни было связано, чем бы ни вызвано. Даже скорее более для процессов, которые выполняются вне компьютерной среды или с минимальным её использованием.
Вот пример. Приём сотрудника на работу. Допустим, случилось чудо (пример из моей практики , и регламент заработал, т.е. руководитель подразделения ( NB - речь про "парциальный" процесс приёма конкретного сотрудника, этапы выявления и формализации кадровой потребности, поиска кандидатов и т.п. в данном процессе не рассматриваются) вовремя подал заявку всем, кому полагается - в отдел МТО, секретариат, бухгалтерию, ИТ-службу и т.п., чтобы подготовили рабочее место, инструмент, спецовку, компьютер, завели аккаунт, почту и прочая. Теперь каждый из получателей заявки должен отработать свои задачи. Конечно, очень "вкусно" сделать некий инструмент workflow (хотя в данном конкретном случае это helpdesk), который бы содержал некий интерактивный чек-лист (на web, с версией для планшета ), да с централизованным "рисованием" маршрута, но это всегда дополнительные затраты, а для "линейных" (особенно - некомпьютерных) сотрудников - лишняя задача в виде "тыкания кнопок".
Так вот, предположим, что чек-листа интерактивного нет (как минимум, его кто-то должен сделать, внедрить и периодически актуализировать), процесс выработан до автоматизма, и вдруг появляется какое-то его изменение. Например, перераспределение функций (тоже реальный пример) - персоналом занималась бухгалтер участка "Зарплата и кадры", а потом компания создала позицию менеджера по кадрам, к которому часть кадровых функций ушла. При этом портала ещё нет (не до жиру, компания СМБ), системы Workflow нет, BPMS автоматизированной нет. Естественно, перераспределение функций влечёт за собой изменение регламента, но в отсутствие интерактивного чек-листа все, кто так или иначе в данном процессе задействованы (как клиенты или исполнители), должны перестроиться. И если для исполнителей можно провести некое мероприятие по актуализации процесса в их сознании (внедрение изменений , то для всех потенциальных клиентов процессов - нет. Если один и тот же начальник расширял/обновлял свой отдел несколько раз в течение последних 2-3 месяцев, то заявку он будет формировать не с нуля (помним, что системы нет, в лучшем случае - электронная почта), а копированием ранее отправленной. Соответственно, без включения адреса нового менеджера по кадрам
Строго говоря, мы приходим к тому, что в качестве обязательного элемента чуть ли ни каждой компании должны быть:
а) Сотрудники, ответственные за нормативно-методическое обеспечение (возможно, на outsource);
б) Система workflow (BPMS) с удобным (в т.ч.) мобильным интерфейсом (весьма вероятно, в дополнение к всему "зоопарку" прочих используемых информационных систем), возможно - облачная (SaaS);
в) Роль ответственного за актуализацию настроек BPMS (может объединяться с п. "а").
Оценки:
/
|
05.03.2014 13:42 |
|
от автора
В статье про BPMS вообще ничего не говорилось. Причем специально. Не хотелось бы переводить обсуждение в плоскость проблем, связанных с эксплуатацией BPMS.
А сотрудники, ответственные за НМД, обязательно должны быть в компании.
Оценки:
/
|
05.03.2014 14:32 |
|
от автора
Не говорилось, но между строчек сочится, как берёзовый сок по весне
А что касается сотрудников, ответственных за НМД - это хорошо, полезно, правильно, но не всем доступно, да и не все собственники бизнеса (особенно в СМБ) это понимают, так что выход - внешние консультанты. Так сказать, CaaS - Сonsulting as a Service (надо бы название запатентовать...)
Оценки:
/
|
12.03.2014 19:05 |
|
от автора
На мой взгляд, если угодно.
Моделирование – процесс прогнозирования реальных результатов управления в соответствии с регламентом. Регламент – закон управления предприятием, который в реальности изменяется в зависимости от множества параметров, предусмотреть характер этих зависимостей как правило затруднительно.
Этот процесс прогнозирования является основной целью моделирования, всё остальное относится к системам автоматизированного управления:
- оптимизация бизнес-процессов и орг. структуры организации,
- накопление информации в контексте процессов,
- генерация для персонала компании информации регламентирующего характера,
- поддержание деятельности по оперативному управлению,
- разработка технических заданий для автоматизации бизнес-процессов.
Цели у них разные, но аппарат может быть совместим.
Цель моделирования определяет необходимость моделирующей программы, необходимость и цена определяют внедрение любой системы, а это определяет блочность моделирующей программы и системы автоматизированного управления.
Оценки:
/
|
13.03.2014 16:43 |
|
от автора
А по-моему ничего лучше для описания деятельности организации с точки зрения процессного подхода, чем IDEF0 так и не придумали. Самое лучшее CASE-средство для построения таких моделей остается BPWin, тем более что интеграция с организационной и информационной моделью, а также динамической моделью там реализована очень хорошо.
Оценки:
1/
|
18.03.2014 11:53 |
|
от автора
Добрый день. Есть примеры подобных автоматизированных систем, работающих через web-броузер?
Оценки:
/
|
18.03.2014 12:32 |
|
от автора
Если говорить о наличии web-порталов, то лично делал порталы на Business Studio 4.0 и iGrafx 2013. Конечно, функционал на сегодня достаточно ограничен. У iGrafx возможностей больше.
Добавить комментарий
Комментировать материалы могут только зарегистрированные пользователи.
Вы можете зарегистрироваться здесь.
|
|