1. Бумажные горы
«Какова трудоемкость описания и регламентации одного бизнес-процесса»? Этот вполне конкретный вопрос часто задают руководители, отвечающие за организационное развитие. Им нужно знать, сколько бизнес-аналитиков привлечь. Очевидно, что нужен какой-то норматив для обоснования численности сотрудников.
Для определения трудоемкости удобно ввести понятие «нормо-процесса». Такой нормо-процесс представляет собой схему на листе формата А4, содержащую от 8 до 12 операций (иногда – больше). Графическое описание нормо-процесса, ввод нужных данных в систему моделирования (текстовое описание операций, описание входов/выходов и событий, формы документов, цели и показатели, методы контроля и т.п.) плюс время на согласование вместе составляют около 4-5 полных рабочих дней работы одного бизнес-аналитика.
Представим себе, что нам нужно полностью регламентировать процессы сбыта крупной компании (3000 человек). Потребуется описать, как минимум, 60-80 нормо-процессов. Такая работа потребует около 400 рабочих дней. Один бизнес-аналитик будет выполнять ее почти 2 года. Очевидно, что нужно выделить больший ресурс. Так обычно и поступают руководители компаний, которые поверили в регламентацию процессов и предприняли активные действия по ихразработке и внедрению. В отдел орг. развития приглашают 4-5 специалистов. Пять специалистов смогут детально описать и регламентировать весь сбыт примерно за 4 месяца. Будет создано большое количество регламентов, которые после утверждения будут доведены до сотрудников сбыта.
Но жизнь не стоит на месте. Внутри и вне компании постоянно все меняется. Необходимо вносить изменения в регламенты, которые уже созданы. Причем изменения в одном регламенте (процессе), как правило, затрагивают и многие другие. Так же возникают изменения в структурных нормативных документах: в должностных инструкциях, положениях о подразделениях. Для поддержки уже существующей регламентной базы необходимо взять еще 2-3 бизнес-аналитиков.Растет бумажная гора регламентов. Растет численность штата бизнес-аналитиков. Растут расходы, а эффективность бизнес-процессов не повышается.
В чем же причина данной проблемы? Что является узким местом? Если бы узким местом было количество бизнес-аналитиков, работающих в компании, то простым увеличением их числа проблема была бы решена. Но это не так. Массив информации по бизнес-процессам становится настолько сложным, что даже 10 человек не могут быстро и эффективно вносить в него изменения. Что же делать? Отказаться от описания и регламентации совсем?! Нет. Надо искать
причины проблем в используемой в компании
технологии работы с регламентирующими документами. Рассмотрим 3 существующих технологических подхода к регламентации, представленные в следующей таблице.
Таблица 1. Технологии работы с регламентирующими документами.
Технология I. Традиционное решение
Традиционное решение (I) предполагает использование среды моделирования только для описания процессов и выгрузки регламентирующих документов. Выгруженный в файл MS Word регламент может быть отправлен нескольким сотрудникам по e-mail для получения замечаний. Полученные замечания вносятся в среду моделирования. Затем выгружается следующая версия файла с регламентом и так далее. После внесения всех замечаний, распечатывается бумажная версия регламента. Далее на бумажном документе собирают согласующие подписи (т.е. в каком-то смысле дублируют при этом предыдущую работу по согласованию). Обратим внимание на тот факт, что сбор подписей на бумажных оригиналах нормативно-методических документов является неотъемлемой чертой корпоративной культуры большинства российских компаний. Далее документ утверждается и в бумажной форме помещается в архив нормативно-методических документов компании.
Технология II. Использование СЭД
При использовании СЭД ситуация очень похожа на предыдущую. Разница в том, что согласование проектов регламентов осуществляется в электронной форме в рамках СЭД (система электронного документооборота). Утверждается регламент так же в СЭД, в т.ч. с использованием ЭЦП (электронная цифровая подпись). Далее регламент в электронном виде помещается, например, в защищенное файловое хранилище. Естественно, на каждый регламент есть своя регистрационно-контрольная карточка, показывающая его историю (в т.ч. версии, дату утверждения и проч.). За счет наличия в СЭД развитых средств поиска сотрудники могут достаточно быстро находить нужные им регламенты. Однако, проблема быстрого изменения связанной группы нормативно-методических документов остается неизменной, то есть внедрение СЭД не позволят решить эту проблему.
Технология III. Web-портал
При использовании web-портала среды моделирования ситуация радикально меняется. Во-первых, нет необходимости формировать какие-либо регламентирующие документы в виде файлов MS Word. Вся информация о процессе представлена на web-портале, причем в интерактивном виде: графическая схема, ответственные сотрудники, требования к выполнению процесса, описание используемых ресурсов, цели и показатели и т.п. Все процессы связаны между собой – можно легко перемещаться от одного процесса к другому, просматривать требования к ресурсам и т.д. Согласование требований к процессу может осуществляться прямо на web-портале, причем с использованием ЭЦП (без необходимости установки СЭД).
Согласованная, утвержденная в электронном виде и размещенная на web-портале информация считается нормативной.
Последнее утверждение в корне меняет подход к регламентации бизнес-процессов в компании. Зачем создавать горы бумажных или электронных (в файловых хранилищах СЭД) регламентов? У каждого сотрудника сегодня есть РС, планшет или смартфон. При необходимости, он обращается к web-порталу компании и практически мгновенно находит нужную ему информацию нормативно-методического характера. Такой подход является в достаточной степени революционным. Для его внедрения нужно твердое желание руководства компании. Кроме того, ограничивающим фактором являются возможности среды моделирования. В следующем разделе мы рассмотрим, какие возможности предлагают современные системы моделирования в области создания и использования web-портала.
2. Сравнительный анализ различных программных продуктов для моделирования бизнес-процессов
Для сравнения мы выбрали лучшие среды моделирования бизнес-процессов: Business Studio 4.0, ARIS 9, Casewise и iGrafx 2013. В следующей таблице 2 представлены их функциональные характеристики с точки зрения работы web-портала.
Таблица 2. Сравнение функциональных возможностей
различных сред моделирования бизнес-процессов в части web-портала.
* Это компенсируется тем, что еще необновленныестраницы обновляются в первую очередь при запросе их пользователем.
Как видно из таблицы 2, современные среды моделирования очень похожи с точки зрения возможностей представления и работы с информацией на web-портале. Однако, есть и различия, которые могут сыграть свою роль при выборе соответствующей системы. Если руководством компании принято решение сделать ставку на безбумажную технологию регламентации процессов на web-портале, то нужно выбирать систему, обеспечивающую наиболее легкую и удобную работу сотрудников организации именно с web-порталом.
Ключевыми требованиями при выборе web-решения могут быть:
• простота и скорость размещения информации на web-портале;
• возможность автоматического обновления информации;
• возможность автоматической интеграции с другими базами данных (учетные системы, ERP) для автоматического вывода на портал информации по плановым и фактическим значениям показателей по бизнес-процессам;
• возможность согласования контента на web-портале с использованием ЭЦП.
3. Выводы
Современный мир быстро меняется. Эти изменения влияют на организацию очень сильно. Невозможно на долго закрепить регламентами бизнес-процессы, которые должны гибко и оперативно подстраиваться под изменяющуюся ситуацию. Российским компаниям еще предстоит переход от бумажной технологии регламентации к простой, удобной и эффективной технологии регламентации деятельности через web-порталы, содержащие знания по выполняемым бизнес-процессам, требования к ресурсам, целяи показателя для управления.
В.В. Репин, к.т.н., Исполнительный директор и партнер ООО «BPM Консалтинг Групп», доцент кафедры Бизнес-информатики и систем управления производством МИСиС.
Июнь 2013 г.
