Комментарии 9
Александр, здравствуйте, спасибо большое вам за статью. С популярностью процессного подхода история очень интересная: с одной стороны упоминания о нём были уже сорок лет назад, а с другой стороны в той же разработке программного обеспечения такого любовного отношения к процессам я нигде не наблюдал.
Подскажите, пожалуйста, а что представляет собой классификатор процессов? Это текстовая база знаний или что-то более динамическое? Существуют ли инструменты, помогающие отследить соответствие деятельности на местах описанным процессам? Хранится ли статистика процессов где-то рядом с классификатором и централизовано или же как-то иначе?
Глеб, Добрый день.
Классификатор процессов представляет собой иерархическую структуру, которая группирует процессы например по видам деятельности и дальше эти группы декомпозируется до процесса. Тем самым мы определяем какие процессы есть в компании. При этом контролируем отсутствия дублирования, т.к. в иерархии двух одинаковых объекта быть не может. Далее мы выстраиваем цепочки создания ценности исходя из процессов, которые определены в классификаторе. Ведем все в Business Studio, так удобней аналитикам определять смежные процессы, которые могут задеть изменения. Для бизнеса классификатор выгружаем и размещаем на wiki.
У нас на данный момент, инструментов, которые отслеживают соблюдения процессов нет. Нам пока рано. Но когда уровень процессной зрелости будет у нас выше, то может рассмотрим process mining. Сейчас отслеживание идет с помощью настроенных отчетов и техникой наблюдения. Статистику пока не храним рядом с классификатором, только готовим структуру отражения достижения kpi каждого процесса связанную непосредственно с описанным процессом.
Но все ведется централизовано.
Подскажите, пожалуйста, каким образом у вас организована интеграция описанных аналитиками бизнес-процессов и реальных процессов организации с учетом их автоматизации?
Используете ли вы исполняемые бизнес-процессы?
Т.к. разработка процессов ведется для проектов под автоматизацию, то разработанные процессы соответствуют действующей автоматизации. У нас очень развито написания детальных инструкций, ссылки на которых присутствуют в регламентах. Т.е. если автоматизация не изменяет ход процесса, то корректируется только инструкция, ссылка которой присутствует в регламенте. Если же автоматизация меняет процесс, то планируется разработка процесса TOBE, который содержит планируемое изменение и в итоги является требованием к автоматизации. Но как писал в статье о существующей проблеме с ранее запущенными проекта, приходится делать описания по уже запущенному функционалу. Но по всем новым запускаемым проектам, если требуются процессы, то они по правилам первичны.
Исполняемые процессы мы не описываем, т.к. у нас нет BPMS, но при разработке функциональных требований, если аналитик считает, что требуется более детальное системное описание работы системы, то шаги процесса детализируется в модели более системного уровня.
Ваше видение к построению процессного подхода очень близко мне - аналогичным образом я развиваю его и в моей компании. Подскажите, как у вас выстроен процесс распределения и/или добавления функционала между подразделениями при оптимизации кросс-функциональных процессов? Абстрактный пример: чтобы выстроить процесс для подразделения X, определить процессные метрики для его мониторинга, необходимо, чтобыподразделение У начало вести совершать дополнительную работу, которой раньше не было. Как правило, на этом этапе могут возникать определенные разногласия) и все это превращается в длительные "согласования", фактически пинг-понг между руководителями функциональных подразделений (особенно, если все "крайне загружены решением бизнес-задач"). Конечно, в зрелом состоянии процессного подхода это должно решаться полномочиями владельцев процессов, но до этого еще небходимо дорасти
А почему не рассмотреть процесс с точки зрения Функций (трудовых). У вас есть подразделения с набором компетенций и полномочий на трудовые функции (см профстандарт) и есть процесс (назовём его сквозной), который "собирается" из этих функций и исх. материала. Те "дополнительная работа" либо должна быть чьей то функцией, либо она не нужна.
Второй момент, параметризуйте согласуемый объект (фин операции см BIAN), и пусть согласующие, определят границы для параметров (в своей зоне ответственности), в определённых условиях. Собственно согласования в таком случае и не будет... а тот кто из руководителей не сможет этого сделать, welcome отсюда.
Стандарт 9001 всё даёт для прекращения пинг-понга, вопрос в его честном внедрении)
Hidden text
Если я правильно Вас понял, то Вы предлагает собрать все функции сотрудников и из-них выстраивать процессы? Если это так, то в любом случае Вам необходимо с начала определить сквозные процессы организации, т.е. что мы и сделали. Второе Вам необходимо определить всевозможные функции сотрудников, обобщенно написать их из проф. стандарта это не позволит Вам выстроить детальный процесс, который будет работать, т.к. в описании процесса кроме последовательности задач, требуется показывать логику процесса, входящие/исходящие данные, исполнителей, временные ограничения, ИТ-системы, которые задействованы. Т.е. мы с начала определяем процесс, его вход и результат, который он должен выдавать, а далее описываем, как мы последовательно достигаем результат, оценивая задача влияет на добавления ценности, если не добавляет, то идет оценка зачем данная задача нужна, если понимаем, что влияет на контроли, соблюдения законодательства, то оставляем, если влияния нет и нет влияния, то убираем. Это бывает сложно доказать, но мы стараемся :)
По поводу "параметризировать", а не то "welcom", это ситуация идеалистическая, в любых случаях нужно всем договариваться, смотреть на загрузки и ресурсы и многое чего еще.
В части Стандарта 9001, то он не останавливает пинг-понг, не помню, где там прописали останову пинг-понга, и я не могу сказать, что у нас большая проблема пинг-понга.
"это ситуация идеалистическая, в любых случаях нужно всем договариваться, смотреть на загрузки и ресурсы и многое чего еще."
А почему Я, как руководитель, должен смотреть на ресурсы и загрузку др. отдела? У меня задачи, в которых я профессионал... ПМ, который везде "ускоряет" процесс, только мешает выстроить систему процессов, а не кучу процессов.
"В части Стандарта 9001, то он не останавливает пинг-понг..."
Без стандарта по Системам (ГОСТ Р 57193), может быть сложновато, но он решает все проблемы.
пс: про пинг-понг, это больше к комментарию, но кот я ответил.
"оценивая задача влияет на добавления ценности, если не добавляет, то идет оценка зачем данная задача нужна..."
Пример: В ТЦ "Зимняя вишня" пришли к выводу, что пожарная безопасность (система/процессы, как хотите) не добавляет ценность... Но СМК/СИ явно ТРЕБУЕТ (ют) безопасности не только для заказчика, но и работника. См управление рисками.
Нельзя договариваться, нельзя! За пивком два ПМ, хрюкнут, оценят и в продакшен...
Вадим, мы не выделяем процессы подразделений. Процессы выделены по "результату", который приносит ценность потребителю (внешнему или внутреннему). Т.е. процессы демонстрирует взаимодействие подразделений (сотрудников), которые нацелены на достижения результата. Из-за этого у нас для каждого процесса выделены Владелец процесса для каждого процесса, который помогает договориться между подразделениями, которые взаимодействуют между собой в процессе, за результат которого он отвечает. Естественно бывают споры при обсуждении процесса, но тут вопрос решается в рамках общих встреч и нахождения компромиссов между бизнес-подразделениями (и такие споры в большинстве своем быстро решаются), а если все зашли в тупик, то идет эскалация на операционного директора, который окончательно принимает решение. Но таких споров я наблюдаю редко, т.к. все связано с проектам, где есть заинтересованность всех и вопрос стоит "Как можно сделать", а не "Я не могу".
Процессный подход на цыпочках, или как выстроить процессы в крупном ритейле