Если я правильно Вас понял, то Вы предлагает собрать все функции сотрудников и из-них выстраивать процессы? Если это так, то в любом случае Вам необходимо с начала определить сквозные процессы организации, т.е. что мы и сделали. Второе Вам необходимо определить всевозможные функции сотрудников, обобщенно написать их из проф. стандарта это не позволит Вам выстроить детальный процесс, который будет работать, т.к. в описании процесса кроме последовательности задач, требуется показывать логику процесса, входящие/исходящие данные, исполнителей, временные ограничения, ИТ-системы, которые задействованы. Т.е. мы с начала определяем процесс, его вход и результат, который он должен выдавать, а далее описываем, как мы последовательно достигаем результат, оценивая задача влияет на добавления ценности, если не добавляет, то идет оценка зачем данная задача нужна, если понимаем, что влияет на контроли, соблюдения законодательства, то оставляем, если влияния нет и нет влияния, то убираем. Это бывает сложно доказать, но мы стараемся :)
По поводу "параметризировать", а не то "welcom", это ситуация идеалистическая, в любых случаях нужно всем договариваться, смотреть на загрузки и ресурсы и многое чего еще.
В части Стандарта 9001, то он не останавливает пинг-понг, не помню, где там прописали останову пинг-понга, и я не могу сказать, что у нас большая проблема пинг-понга.
Вадим, мы не выделяем процессы подразделений. Процессы выделены по "результату", который приносит ценность потребителю (внешнему или внутреннему). Т.е. процессы демонстрирует взаимодействие подразделений (сотрудников), которые нацелены на достижения результата. Из-за этого у нас для каждого процесса выделены Владелец процесса для каждого процесса, который помогает договориться между подразделениями, которые взаимодействуют между собой в процессе, за результат которого он отвечает. Естественно бывают споры при обсуждении процесса, но тут вопрос решается в рамках общих встреч и нахождения компромиссов между бизнес-подразделениями (и такие споры в большинстве своем быстро решаются), а если все зашли в тупик, то идет эскалация на операционного директора, который окончательно принимает решение. Но таких споров я наблюдаю редко, т.к. все связано с проектам, где есть заинтересованность всех и вопрос стоит "Как можно сделать", а не "Я не могу".
Т.к. разработка процессов ведется для проектов под автоматизацию, то разработанные процессы соответствуют действующей автоматизации. У нас очень развито написания детальных инструкций, ссылки на которых присутствуют в регламентах. Т.е. если автоматизация не изменяет ход процесса, то корректируется только инструкция, ссылка которой присутствует в регламенте. Если же автоматизация меняет процесс, то планируется разработка процесса TOBE, который содержит планируемое изменение и в итоги является требованием к автоматизации. Но как писал в статье о существующей проблеме с ранее запущенными проекта, приходится делать описания по уже запущенному функционалу. Но по всем новым запускаемым проектам, если требуются процессы, то они по правилам первичны.
Исполняемые процессы мы не описываем, т.к. у нас нет BPMS, но при разработке функциональных требований, если аналитик считает, что требуется более детальное системное описание работы системы, то шаги процесса детализируется в модели более системного уровня.
Классификатор процессов представляет собой иерархическую структуру, которая группирует процессы например по видам деятельности и дальше эти группы декомпозируется до процесса. Тем самым мы определяем какие процессы есть в компании. При этом контролируем отсутствия дублирования, т.к. в иерархии двух одинаковых объекта быть не может. Далее мы выстраиваем цепочки создания ценности исходя из процессов, которые определены в классификаторе. Ведем все в Business Studio, так удобней аналитикам определять смежные процессы, которые могут задеть изменения. Для бизнеса классификатор выгружаем и размещаем на wiki.
У нас на данный момент, инструментов, которые отслеживают соблюдения процессов нет. Нам пока рано. Но когда уровень процессной зрелости будет у нас выше, то может рассмотрим process mining. Сейчас отслеживание идет с помощью настроенных отчетов и техникой наблюдения. Статистику пока не храним рядом с классификатором, только готовим структуру отражения достижения kpi каждого процесса связанную непосредственно с описанным процессом.
Если я правильно Вас понял, то Вы предлагает собрать все функции сотрудников и из-них выстраивать процессы? Если это так, то в любом случае Вам необходимо с начала определить сквозные процессы организации, т.е. что мы и сделали. Второе Вам необходимо определить всевозможные функции сотрудников, обобщенно написать их из проф. стандарта это не позволит Вам выстроить детальный процесс, который будет работать, т.к. в описании процесса кроме последовательности задач, требуется показывать логику процесса, входящие/исходящие данные, исполнителей, временные ограничения, ИТ-системы, которые задействованы. Т.е. мы с начала определяем процесс, его вход и результат, который он должен выдавать, а далее описываем, как мы последовательно достигаем результат, оценивая задача влияет на добавления ценности, если не добавляет, то идет оценка зачем данная задача нужна, если понимаем, что влияет на контроли, соблюдения законодательства, то оставляем, если влияния нет и нет влияния, то убираем. Это бывает сложно доказать, но мы стараемся :)
По поводу "параметризировать", а не то "welcom", это ситуация идеалистическая, в любых случаях нужно всем договариваться, смотреть на загрузки и ресурсы и многое чего еще.
В части Стандарта 9001, то он не останавливает пинг-понг, не помню, где там прописали останову пинг-понга, и я не могу сказать, что у нас большая проблема пинг-понга.
Вадим, мы не выделяем процессы подразделений. Процессы выделены по "результату", который приносит ценность потребителю (внешнему или внутреннему). Т.е. процессы демонстрирует взаимодействие подразделений (сотрудников), которые нацелены на достижения результата. Из-за этого у нас для каждого процесса выделены Владелец процесса для каждого процесса, который помогает договориться между подразделениями, которые взаимодействуют между собой в процессе, за результат которого он отвечает. Естественно бывают споры при обсуждении процесса, но тут вопрос решается в рамках общих встреч и нахождения компромиссов между бизнес-подразделениями (и такие споры в большинстве своем быстро решаются), а если все зашли в тупик, то идет эскалация на операционного директора, который окончательно принимает решение. Но таких споров я наблюдаю редко, т.к. все связано с проектам, где есть заинтересованность всех и вопрос стоит "Как можно сделать", а не "Я не могу".
Т.к. разработка процессов ведется для проектов под автоматизацию, то разработанные процессы соответствуют действующей автоматизации. У нас очень развито написания детальных инструкций, ссылки на которых присутствуют в регламентах. Т.е. если автоматизация не изменяет ход процесса, то корректируется только инструкция, ссылка которой присутствует в регламенте. Если же автоматизация меняет процесс, то планируется разработка процесса TOBE, который содержит планируемое изменение и в итоги является требованием к автоматизации. Но как писал в статье о существующей проблеме с ранее запущенными проекта, приходится делать описания по уже запущенному функционалу. Но по всем новым запускаемым проектам, если требуются процессы, то они по правилам первичны.
Исполняемые процессы мы не описываем, т.к. у нас нет BPMS, но при разработке функциональных требований, если аналитик считает, что требуется более детальное системное описание работы системы, то шаги процесса детализируется в модели более системного уровня.
Глеб, Добрый день.
Классификатор процессов представляет собой иерархическую структуру, которая группирует процессы например по видам деятельности и дальше эти группы декомпозируется до процесса. Тем самым мы определяем какие процессы есть в компании. При этом контролируем отсутствия дублирования, т.к. в иерархии двух одинаковых объекта быть не может. Далее мы выстраиваем цепочки создания ценности исходя из процессов, которые определены в классификаторе. Ведем все в Business Studio, так удобней аналитикам определять смежные процессы, которые могут задеть изменения. Для бизнеса классификатор выгружаем и размещаем на wiki.
У нас на данный момент, инструментов, которые отслеживают соблюдения процессов нет. Нам пока рано. Но когда уровень процессной зрелости будет у нас выше, то может рассмотрим process mining. Сейчас отслеживание идет с помощью настроенных отчетов и техникой наблюдения. Статистику пока не храним рядом с классификатором, только готовим структуру отражения достижения kpi каждого процесса связанную непосредственно с описанным процессом.
Но все ведется централизовано.