Решение проблемы выбора инструментов описания бизнес-процессов зависит от размеров и целей компании, и самого проекта описания бизнес-процессов (статья "С чего начинать формализацию бизнес-процессов?").
В случае внедрения системы менеджмента качества ИСО 9000:2000 используется процессный подход, что значительно сужает спектр применяемых инструментов. их можно условно разделить на 2 группы: поддерживающие нотацию SADT/IDEF0 (BPwin, ERwin и др.) и универсальные (к примеру, MS Visio).
В случае автоматизации деятельности выбор методологий описания бизнес-процессов зависит от предпочтений разработчиков, от программных средств, которыми они привыкли или предпочитают пользоваться (BPwin, Erwin, Oracle Designer, ARIS, Rational ROSE и др.). Иногда для разработчиков достаточно иметь набор форм и внутренних документов компании с текстовым описанием регламентов документооборота, и порядков выполнения работ. Тогда основная часть работы по описанию бизнес-процессов для последующей автоматизации ложится на разработчиков программного обеспечения.
Существуют серьезные риски по отклонению от истинных пожеланий пользователей:
1. Если документы и формы устарели, а разработчики об этом не проинформированы.
2. Если не проводилось интервьюирование будущих конечных пользователей информационной системы или проводилось в недостаточной мере.
3. Если с будущими конечными пользователями не согласовывались предварительные планы или промежуточные результаты, не говоря уже о техническом задании на разработку.
4. Если пользователи не понимают язык, на котором написаны требования к будущей системе, или схемы, которые им необходимо согласовать.
Меньше указанных рисков возникает в том случае, когда в организации уже разработаны необходимые требования к системе, схемы нужного и понятного всем формата, существует четкая структура документации, регулярно проверяется ее актуальность и в документацию вносятся изменения. Но такая ситуация из рода фантастики, потому что внешняя и внутренняя среда организации подвержена постоянным изменениям, а для автоматизации необходима подробная детализация всех действий и потоков в разрезе ответственных, сроков и условий. Получив задание и разрабатывая информационную систему в течение 2-3-х месяцев, которая не может обеспечить необходимой гибкости, разработчик рискует произвести на свет "мертвую" систему, которая уже никому не будет нужна. Заказчик теряет деньги, а разработчик свой имидж, потому что не может поместить этот продукт в портфель разработок с успешным внедрением, или рискует не получить оплаты за выполненную работу, если договор составлен не в его пользу.
Оптимальным вариантом будет являться описание бизнес-процессов (или их аудит), незадолго до начала автоматизации с полным соблюдением этапов: разработка модели организации "как есть" (as is), анализ модели "как есть", разработка модели "как надо" (to be), разработка плана перехода из состояния "как есть" в состояние "как надо", внедрение изменений и построение организации "как надо".
Методики описания (структуризации) и проведения обследования бизнес-процессов можно найти в многочисленных открытых источниках. Подробная методика проведения обследования бизнес процессов описана В.К. Чаадаевым "Бизнес-процессы в компаниях связи". - М.: Эко-Трендз, 2004, с.151-168. Много полезной, качественной информации, касающейся практики формализации бизнес-процессов можно найти у авторов Ковалев Сергей Михайлович, Ковалев Валерий Михайлович на сайте "Бизнес-инжиниринговые технологии" http://www.betec.ru/index.php?id=8&sid=01
Сравнительный анализ нотаций ARIS и IDEF и продуктов их поддерживающих (ARIS Toolset/ BPwin) провел В.В. Репин http://quality.eup.ru/MATERIALY3/aiatbp.html, где обозначил плюсы и минусы того и другого метода. О преимуществах и недостатках применения средств моделирования Rational Rose фирмы Rational Software пишет Павел Сахаров в статье "Rational Rose, BPwin и другие - аспект анализа бизнес-процессов" http://www.iteam.ru/publications/it/section_51/article_1686/ и Новичков А.Н. в статье "Rational Rose для разработчиков и ради разработчиков" http://www.citforum.ru/programming/application/rrose.shtml.
Кроме этого существует масса информации по использованию программных продуктов, но, на мой взгляд, во всех этих нотациях есть иные недостатки:
1. Невозможность в единой диаграмме изобразить временные регламенты и все виды потоков, необходимые для детального описания (либо разработчик сам должен придумать методологию как это сделать, выйдя за рамки стандартной нотации).
2. Необходимость предварительного обучения пользователей (ответственных и исполнителей) чтению используемых нотаций, чтобы разработанное описание бизнес-процессов можно было использовать не только в целях автоматизации, но и обеспечить использование в практике и регулярный анализ с целью дальнейшего совершенствования.
В связи с этим, в целях оптимизации деятельности все чаще используются собственные разработки, как внутренних специалистов, так и специалистов консалтинговых компаний. В основном это интерпретированные или дополненные вышеуказанные методологии, а также диаграммы DFD, WFD или Swimmer lanes. Именно по этой причине у ЗАО "БИТЕК" появился собственный продукт для описания бизнес-процессов "Бизнес-инженер Профи". Судя по описанию, их продукт ближе и понятней потребителям.
Часто на форумах задается вопрос: "Как с наименьшими затратами описать и проанализировать бизнес-процессы?". На что можно услышать ответ, что самый дешевый способ - это карандаш и лист бумаги. Не утрируя, можно обойтись стандартным пакетом MS Office. Схемы, подобные Swimmer lanes можно выполнять в MS Excel, хотя это неудобно и трудоемко по сравнению с более функциональным пакетом MS Visio. Общая стоимость этого программного обеспечения сравнительно небольшая. Для сравнения, пакет специализированного программного обеспечения для описания бизнес-процессов Business studio стоит от 44 тыс. рублей и требует наличия MS Visio.
Выделяют текстовое и графическое описание бизнес-процессов. Графическое изображение способствует сокращению времени на восприятие и понимание бизнес-процессов.
Независимо от способа, можно выделить следующие этапы описания бизнес-процессов.
1. Определить основные процессы создания добавленной стоимости и вспомогательные процессы, которые можно разделить на обеспечивающие и управляющие, в некоторых случаях выделяют усовершенствующие (НИОКР) (детализация 1 уровня).
2. Рассмотреть направления деятельности объекта и провести детализацию основных процессов до подпроцессов. (Детализация 2 уровня).
3. Изучить организационную структуру исследуемого объекта и (если это возможно) функции подразделений. Если функции не формализованы, то необходимо определить их с помощью интервьюирования.
4. Составить матрицу ответственности штатных единиц за процессы 1 и 2 уровня "как есть" (если происходит дублирование или ответственные разного субординационного уровня, отразить "как есть" и сформировать предложения по усовершенствованию управления процессами "как должно быть", и что нужно для этого сделать). Иногда в холдинговой структуре объединены предприятия, имеющие схожие направления деятельности, но имеющие разные организационные структуры и штатные расписания, тогда в целях сокращения времени на разработку и внедрение индивидуальных процессов, разрабатывается модель "как должно быть", где хозяевам процессов и исполнителям присваиваются наименования, которым даются определения (какие специальности могут относиться к данному наименованию или это может быть назначенное в приказном порядке лицо).
5. Изучить взаимосвязь информационных, материальных и финансовых потоков.
6. Далее следует детальное описание процедур, которое можно выполнить различными способами.
Рассмотрим только те способы, которые не предполагают наличия специального программного обеспечения.
Основными целями этих способов описания будут:
формализация имеющихся процессов для прозрачности и использования в работе при взаимодействии специалистов;
выявление дублирования функций, отчетов и нерациональных потоков информации, документов и т.п.;
Качество описания, к которому необходимо стремиться - это понятность и простота для пользователей.
Процесс - совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующих входы в выходы.
Документ, содержащий описание бизнес-процесса может иметь разные наименования, в зависимости от принятой системы и структуры нормативных документов (в соответствии с системой менеджмента качества, в соответствии с международными или национальными государственными стандартами): инструкция, порядок, положение, стандарт предприятия, процедура управления.
В западной практике и практике российских компаний распространено понятие - процедура управления (Management procedure).
Процедура управления - установленный порядок ведения, рассмотрения чего-либо, например порядок следования процессов управления: фиксирование рассогласования в заданном ходе производства, оценка степени критичности этого, принятие оптимального экономически эффективного решения, устраняющего рассогласование. (Управление организацией: Энцикл. слов.-М., 2001)
Процедура управления состоит из управленческих операций (технологически, логически нерасчленимых операций, например сравнения заданного и фактического сбыта; исключение из операции любого показателя сбыта лишает ее экономического смысла). (Управление организацией: Энцикл. слов.-М., 2001)
Процедура управления включает пооперационную функциональную схему порядка выполнения операций процесса и описание операций управления, где излагается организация процесса с использованием информационной системы, назначение документов, их формы, способы их подготовки и передачи. В описании операций последовательно излагается:
кто выполняет (подразделение, должность);
что выполняет;
когда выполняет (или при каких условиях);
какой результат выполнения операции.
Ответы на все эти вопросы необходимо отразить в схеме бизнес-процесса. Тогда он будет иметь практическую значимость, как для исполнителей, так и для программистов, которые будут заниматься автоматизацией или модернизацией информационной системы, поддерживающей бизнес-процесс.
С помощью нотаций SADT/IDEF0 удобно рассмотреть процессы верхнего уровня (1 и 2 уровень детализации). Использование этой нотации дает разработчику и пользователю общее понимание процессов организации и их взаимосвязей, понятие об используемых в процессах ресурсах, о входных и выходных потоках, и управляющих воздействиях.
Процессы 2 уровня уже можно описывать в отдельных документах, где детализация 3 и 4 уровня могут быть объединены в рамках одного документа.
На практике встречается несколько вариантов такого объединения и графического изображения бизнес-процессов, которые являются видоизмененными общепринятыми нотациями в целях упрощения восприятия пользователями.
1 Способ. Горизонтальная функциональная схема. Бизнес-процесс вытягивается горизонтально по оси времени и разбивается на подпроцессы (операции). Указывается наименование подпроцесса и его длительность (или временные ограничения "до ХХ числа месяца", "в течение 1 рабочего дня"). Процесс изображается последовательно с использованием простейших обозначений: "овал" - структурное подразделение, "прямоугольник" - документ, "цилиндр" - информационная система, которая имеет связь с документом. Таким образом, описание представляет собой цепочку "овалов" и "прямоугольников". "Прямоугольники" вертикально связывают с "цилиндрами", если работа с документом производится в информационной системе. Снизу под каждым подпроцессом или под каждым "овалом" можно прописать основные функции.
Таким же образом, поделив бизнес-процесс на подпроцессы и обозначив наименования и длительность операций можно дополнить нотацию Swimmer lanes, расположив дорожки горизонтально. Если в бизнес-процессе участвуют подразделения разного уровня управления, такая схема представляется наиболее удобной.
Плюсы такой схемы в том, что на практике она понятна всем без исключения и не требует специальной подготовки для ее использования, охотно воспринимается пользователями, может рассматриваться самостоятельно без пояснений, легко поддается корректировке.
Минусы в том, что такой способ не дает целостности восприятия процесса, эта схема не подразумевает отражения материальных потоков и не показывает связей с другими подпроцессами. Описание бизнес-процесса занимает значительный объем в несколько листов.
2 Способ. Вертикальная пооперационная схема.
Первый вариант напоминает нотацию Swimmer lanes. Заголовок (шапка) располагается горизонтально: "Наименование операции (подпроцесса)", "Ответственный 1", "Ответственный 2", "Ответственный Х", "Срок выполнения операции" (до ...). Вертикально располагают подпроцессы и операции. В дорожках ответственных изображают описание документооборота и информационных потоков: "прямоугольник" - документ, "треугольник" - работа над документом, "круг" - передача документа, "цилиндр" - информационная система, с которой связан документ. Существует еще несколько обозначений, использующихся в подобных схемах, но на практике указанных обозначений вполне достаточно для описания.
Плюсы те же, что и в первом способе. Дополнительный плюс в том, что такая схема имеет более сжатый вид, компактна, удобна для быстрого понимания процесса, весь процесс можно отразить на 1-м листе.
Минусы в том, что эта схема не подразумевает отражения материальных потоков и не показывает связей с другими подпроцессами.
Другой вариант вертикальной пооперационной схемы представляет собой пошаговую последовательную процедуру. Заголовок (шапка) располагается горизонтально: "Наименование операции (подпроцесса)", "Ответственный", "Описание операции", "Входные/выходные документы, ввод в информационную систему и связь с другими процессами". Процесс вертикально вытянут во времени. Такая процедура более детально отражает каждый шаг или действие ответственного лица, документы, поступающие на вход и на выход, формы которых отражаются в приложениях. Начало процесса обозначается "овалом", в котором указывается событие, после которого запускается процесс. Действия описываются во взаимосвязанных "прямоугольниках". Время выполнения шага указывается на стрелке над прямоугольником. В дорожке "Входные/выходные документы..." отражается документ, поступающий "в" или "из" прямоугольника-действия. Блок принятия решения изображается либо "ромбом", либо заменяется двумя-тремя "шестигранниками", отражающими саму альтернативу, сам ситуативный вариант, например: "Клиент готов подождать" и "Клиент не желает ждать". Действия разграничиваются горизонтальными линиями по ответственным в пределах подпроцесса. В документе, содержащим данную схему процесса приводятся показатели результативности процесса, и обозначается "хозяин" процесса.
Плюсы те же, что и в первом способе. Дополнительные плюсы в том, что такая схема более детально описывает каждое действие, вплоть до конечного исполнителя, в одной схеме процесса отражены процессы 3 и 4 уровней, и можно отразить последующие уровни. В этой схеме отражается связь с другими процессами, можно отразить материальные, информационные и документальные потоки в одной схеме, рассчитать время выполнения процессов.
Минусы в том, что эта схема предназначена для исполнителей, специалистов по информационным технологиям, специалистов службы по персоналу, но неудобна для руководителей высшего звена, которым необходимо получить максимум информации в более короткий срок, не углубляясь в детальное описание.
Для руководителей более удобен первый вариант схемы. В таком случае удобней всего отразить в документе и тот и другой вариант схемы, дав возможность пользователям разного уровня компетенций получить необходимую информацию.
Чем проще выглядит информация для непосредственных исполнителей, тем легче получить от них обратную связь и внести необходимые коррективы. Это экономит средства на массовое обучение персонала и снижает риски неприятия нововведений.
"Будь проще, и люди к тебе потянутся!" - народная мудрость. На одном из форумов был другой вариант-продолжение: "... - простые, безыскусные, незатейливые люди" (с) zh-an. Именно так! Результатом измышлений на тему бизнес-процессов будут пользоваться все, в основной своей массе не гении, а обычные люди. В этой связи хочется еще раз напомнить статью Викентьева И.Л. "БИЗНЕС-ПРОЦЕСС.RU: 5 + 2 = 0" http://www.triz-chance.ru/business.html.