Боюсь, что ТС не совсем корректно сформулировал вопрос. BPMN - это одна из нотаций, в которой можно описывать схемы бизнес-процесса. Задача "внедрение нотации" выглядит несколько странно. Внедрение процессного управления может быть связано с теми или иными ИТ-инструментариями и нотациями, но в общем и целом совсем не обязательно, иногда достаточно простого человеческого языка. Может быть, подразумевалось внедрение BPM S (то есть, системы управления бизнес-процессами)? Если это так, то расскажите про пункт д) немного подробнее. ERP-система уже внедрена? Какая именно это ERP-система? Описаны ли в какой-либо нотации бизнес-процессы, автоматизированные самой ERP-системой?

BPMS используется для обеспечения гибкости процесса и возможности его быстро и удобно модифицировать. Если вы намерены внудрять BPMS, то должны отдавать себе отчет, какие цели вы пытаетесь достичь. ERP-система значительно более "жесткая". Если вы намерены использовать связку BPMS+ERP, вы должны понимать, что некоторые части БП у вас будут плавно перетекать из одной системы в другую и при этом они будут выполнены из существенно разного "материала" - одни из гибкого "пластилина", другие из "бетона", с великим трудом поддающегося изменениям. Соответственно, гибкость и изменчивость процессов у вас получится частичной как некоторой смеси "бетонных блоков", соединенных "пластилиновыми" сочленениями. Если у вас 90% БП находится в ERP-системе, то нужно тщательно подумать над тем, способны ли 10% "пластилина" обеспечить ту гибкость, которую вы ожидаете. Если же за пределами ERP-системы остается значительная часть неохваченных ERP-системой бизнес-процессов, желательно озвучить хоть какую-то информацию о том, что это за процессы. И вообще, что за предприятие, чем занимается, какие масштабы.

АБ, с комментарием согласен. :)

bagrat4. Цель внедрения-именно переход на процессное управление. За это дело взялись всерьез, потому как причин до чертовой матери и это результат тягостных размышлений об “остаться на плаву ”Существует несколько разновидностей процессного управления, каждое с своими акцентами. Одни из них дают наибольший эффект в одних случаях, другие в других. В частности, Lean (==JIT) делает акцент на увеличении скорости потока создания ценности и устранении "муда" (непроизводительных затрат, прежде всего, времени). Six Sigma и TQM делают акцент на качестве процессов и продукции. TOC делает акцент на способах увеличения пропускной способности предприятия (приносит значительный эффект в условиях превышения спроса над предложением). Реинжиниринг бизнес-процессов по Хаммеру и Чампи занимается проектной оптимизацией от "as is" к "to be". Подход BPM, о котором упомянул АБ, и Кайдзен акцентируются на постепенных мелких и частых изменениях процессов, которые позволяют производить оптимизацию наименее болезненно. Можно, конечно, пытаться достичь всего и сразу, но реально получится, возможно, какая-то совокупность двух основных подходов. Я полагаю, что Lean, к примеру, для вас будет слишком труден в освоении, потому что вы используете ERP-систему, функционал которой не подразумевает использования ничего подобного канбан или маркировки потоков, применяемой в TOC. В то же время, некоторые компоненты этих подходов можно использовать и с 1С:УПП, тем более, что внутрицеховое управление, как Вы сами заметили, в ней не автоматизировано. Поэтому внутрицеховое управление может быть подчинено отчасти принципам Lean, TOC и/или каким-то еще. Если Lean, то вы можете попробовать по чуть-чуть сокращать размеры партий внутреннего перемещения, или даже попробовать полностью перейти на канбан. Если TOC, то вы можете вручную маркировать какими-нибудь цветными флажками партии, проходящие через выявленные "бутылочные горлышки" и проходящие мимо - без какого-либо участия ИТ-систем. Да, разумеется, для этого потребуется утвердить регламенты (Вы всё правильно изложили). Однако, имеет ли смысл превлекать для внутрицехового управления BPM-систему, тут нужно посмотреть и прикинуть. Рекомендую обратиться за консалтингом, например, к тому же АБ (он на этом собаку съел). Однако, вам нужно четко представлять, чего вы ходите добиться переходом на процессное управление. Переход на процессное управление ради перехода на процессное управление - это что-то вроде "автоматизации ради автоматизации". :)

Если вы хотите видеть сквозные БП и управлять из одного места, и при этом не предполагаете сколь-нибудь значительной и/или частой модификации БП, то интеграция BPMS и ERP может сыграть с вами дурную шутку. Потому что часть БП будет контролироваться ERP-системой, а часть BPM-системой. У вас по-просту не будет какого-то одного места, посмотрев в которое вы сможете увидеть весь процесс целиком, и выполняющиеся его части. Вы будете видеть "хвост слона" в одной системе, а "хобот слона" в другой. Целиком "слона" просто не будет видно нигде. Поэтому, если задача стоит именно так, то вам нужно "допиливать" ERP-систему, либо внедрять вместо использующейся сейчас другую, ориентированную на решение задач более детального планирования, в том числе внутрицехового.

bagrat7.Упоминание о жесткости ERP я не принимаю . Архитектура и возможности платформы 1с позволяет быть гибкой . 6-10 лет назад я бы так не заявлял. Это давно не проблема для тех кто научился такие системы поддерживать.И, тем не менее, вы не сможете в ERP-системе, в которой в настоящий момент исполняются экземпляры БП, взять и в корне изменить маршрут БП "на ходу", да еще и не выгоняя пользователей из системы. Вы не сможете вносить изменения в схему БП каждый день так, чтобы сама система "помнила", что каким было и по каким маршрутам что должно обрабатываться, поскольку стартовало в разные дни, и при этом экземпляры БП хранятся в системе стартовавшими и незавершенными по три месяца (потому что таков их естественный цикл). А в BPMS подобное возможно. Гибкость имеет огромную ценность для процессного управления, но не та, которую Вы видели в 1С, а другая, совершенно иного порядка. BPMS внедряют там, где основной выигрыш получается именно за счет подобной гибкости. Насколько я понимаю, вы еще к ней не совсем готовы, раз вас устраивает гибкость УПП. :) И, соответственно, не она является целью вашего проекта. Если это так, если я правильно понял, если вам нужно только сквозное видение "застывшего" (малоизменчивого) процесса от стратегического планирования до цехового уровня, вам нужно либо "допиливать" ERP, либо интегрировать ERP (которую всё равно придется "допиливать") с системами цехового и производственного планирования + подключать BI-системы (аналитические).

Модератор: По ошибке удалил сообщение bagrat. Приношу извинения. Ниже приводится текст сообщения

bagratGarya , ВикторКо и все, все. Спасибо за отклики
Для начала Garya выделю ваше - для меня как основное и для закваски :
1. ” В то же время, некоторые компоненты этих подходов можно использовать и с 1С:УПП, тем более, что внутрицеховое управление, как Вы сами заметили, в ней не автоматизировано. Поэтому внутрицеховое управление может быть подчинено отчасти принципам Lean, TOC и/или каким-то еще. ” и “Однако, имеет ли смысл превлекать для внутрицехового управления BPM-систему, тут нужно посмотреть и прикинуть ” - Собственно так и сделали т.е. некоторые производства уже работают по схеме “вытягивания и точно в срок ”. Уже полгода идет “доводка ” регламентов управления. Действительно насчет BPM-системы смотрим и прикидываем …и разумеется корректируем требования по модернизации 1с (или изучаем различные MES-решения для выводов). Сторонний колсантинг здесь малоэффективен, поскольку должен работать принцип “как потопаешь- так и полопаешь”. Поэтому топы (под контролем Ген.дира) эти модернизации рожают вместе с it-технологами (это те кто процессы производства сопровождает от it ), отслеживают и координируют внедрение и попутно репу чешут, как сделать так чтобы устранить ошибки, потому что ответственные исполнители плешь проедают своими претензиями. При этом орг. Структура пока остается функциональной. Руководством дана установка что модернизация БП не акция, а процесс в соответствии с постоянно меняющимися внешними вызовами- это ответственность топов и пока тут много вопросов какими процедурами эту установку конкретно воплощать в жизнь.

2. “Если вы хотите видеть сквозные БП и управлять из одного места, и при этом не предполагаете сколь-нибудь значительной и/или частой модификации БП, то интеграция BPMS и ERP может сыграть с вами дурную шутку. Потому что часть БП будет контролироваться ERP-системой, а часть BPM-системой” - а так оно и есть…. И все шутки сверхдурные. Но ведь на бульдозере элегантный вираж не сделаешь. Надо ворочать тем ERP, чем хлебаешь.

“У вас по-просту не будет какого-то одного места, посмотрев в которое вы сможете увидеть весь процесс целиком, и выполняющиеся его части. Вы будете видеть "хвост слона" в одной системе, а "хобот слона" в другой. Целиком "слона" просто не будет видно нигде. Поэтому, если задача стоит именно так, то вам нужно "допиливать" ERP-систему, либо внедрять вместо использующейся сейчас другую, ориентированную на решение задач более детального планирования, в том числе внутрицехового” - не то слово, хорошо бы хвост, а то обычно различается что ниже…… и то уже поздно, потому как запах дурной. Насчет допиливания и прочая я уже указал выше.Но природа такого проекта уже иная…..это уже требования заинтересованного топа, который прошибает головой у гендира бюджет для него.Такая схема itшникам только в радость.
Теперь очень важное- это” не будет какого-то одного места, посмотрев в которое вы сможете увидеть весь процесс целиком, и выполняющиеся его части.” - хочешь не хочешь такое место не может не быть, процесс управления бизнесом не прервешь и оно в разное время имеет разные орг. Формы. Разумеется там где размыто видится хвост, но по отдельным признакам почему то напоминает хобот…..все равно конечные управленческие решения просто обязаны быть, хотя бы через планерку у Гендира. Рынок ненавязчиво эдак напоминает. Так вот: как вам видится самим организационно это самое место?.Если есть практика-поделитесь.
3. Теперь это:
"Упоминание о жесткости ERP я не принимаю . Архитектура и возможности платформы 1с позволяет быть гибкой . 6-10 лет назад я бы так не заявлял. Это давно не проблема для тех кто научился такие системы поддерживать".
“И, тем не менее, вы не сможете в ERP-системе, в которой в настоящий момент исполняются экземпляры БП, взять и в корне изменить маршрут БП "на ходу", да еще и не выгоняя пользователей из системы. Вы не сможете вносить изменения в схему БП каждый день так, чтобы сама система "помнила", что каким было и по каким маршрутам что должно обрабатываться, поскольку стартовало в разные дни, и при этом экземпляры БП хранятся в системе стартовавшими и незавершенными по три месяца (потому что таков их естественный цикл). А в BPMS подобное возможно. Гибкость имеет огромную ценность для процессного управления, но не та, которую Вы видели в 1С, а другая, совершенно иного порядка. BPMS внедряют там, где основной выигрыш получается именно за счет подобной гибкости”.
Очень интересно.Что это за процессы такие-дайте пример.“А в BPMS подобное возможно” - охотно верю, а на практике как ? , как это персонал так же гибко перестраивается под новый, гибкий БП да на ходу ? . Как это переиграть оперативно кучу процедур, согласовать, утвердить, иструктировать,сделать полигон по возможности, проанализировать неизбежные ошибки, исправить их и т.д.Если можно опишите вкратце, что Вы имели ввиду конкретно утверждая такое.Свое же утверждение я конкретизирую так : сначала топчется БП-тропинка, потом поверх утоптаного кладем гравий, потом асфальт (идея-БП проект, рабочий регламент бумажного БП, работа и оценка решения, выход при необходимости на IT-проект, реализация проекта, рабочая доработка с ответственными пользователями).Бывает и так что идея хороша, но в ручном варианте терпимо и от it-проекта можно воздержаться, оптимальней и дешевле выходит.Насчет большей оперативности....? И в какой области ...может в продажах, но опять ни один проект там без изменений в IT технологиях не реализовывается... Вроде с оперативностью реагирования проблем нет.И еще : представьте себе общий частный случай---длинющий БП: а) Подготовка конструкт спецификации, б)Нормирование затрат материалов. в)Расчет нормативной себестоимости нового изделия г) расчет потребности материалов под план выпуска. д) Расчет заказов на поставку…..и хватит. В этой цепочке довольно частые изменения. Со временем выработался механизм гибкого реагирования всех компонентов этой системы (управленческие регламенты,методики расчетов, корректировки ПО, адаптации решений, поддержка решений ). И как мне при помощи BPMS оперативно провести изменения в куче различных процедур в указанной цепочки, особенно в расчетно-аналитической обработки данных. Я например BPMS рассматриваю только как неплохой механизм отслеживания выполнения БП в разрезе выделенных этапов. (Вродь и учили нас так.) Это неправильно?. Или он еще и дает мне исполнительный код по интересующим меня расчетам и др. обработкам ?. Жду от Вас терпеливых разьяснений.

3. Виктору Ко. Спасибо за участие. Насчет БП выполняемых вне ERP-совершенно согласен и это аксиома. Потому, повторяюсь, и поддерживаем систему регламентов, как основное условие работоспособности действующей ERP “человекомашиноой корп инф сист ”. Поскольку работаем над практическим переходом на процессное управление ,я извините, вновь повторюсь, что озабочен вопросами: “ Что это за конкретные практические шаги при которых: А) неоходимо перейти на процессное управление (изменение орг. Структуры, дележка полномочий персонала и руководства, компромиссы и соглашения между управлением БП и ресурсами функционалов и т.д. )”
Б)Что из себя представляют конкретно соглашения о взаимодествии ERP и BPMS на практике. Как видите Garya (ему вновь поклон) озадачивает меня по этим вопросам.
Думаю, счас я не один такой озабоченный переходом на процессное управление и может кто-нибудь сочувствия ради и душевной сердобольности укажет мя грешному на какие грабли не наступать, хотя бы по пути в ад.

4. Блин. Опять много.

bagratСторонний колсантинг здесь малоэффективен, поскольку должен работать принцип “как потопаешь- так и полопаешь”.Ну, тут не соглашусь. Консалтинг консалтингу - рознь. У меня такое ощущение, что на вашем предприятии пытаются решить многогранную, комплексную проблему "казачьим наскоком". Лучше всё-таки обратиться к людям с опытом. Только к таким, которые действительно знают что и как делать и могут помочь, а не требуют деньги лишь за "навес лапши на уши". :) Чтобы снизить подобные риски, нужно провести референс-визиты.

bagratСобственно так и сделали т.е. некоторые производства уже работают по схеме “вытягивания и точно в срок ”.Остается только недоумевать, почему вы выбрали 1С:УПП. Есть ERP-системы, которые поддерживают канбан-планирование и APS, с помощью которого в одной системе можно реализовать и цеховое планирование, и тактическое, и стратегическое. SyteLine, например.

bagratТак вот: как вам видится самим организационно это самое место?.Если есть практика-поделитесь.Обычно используют ETL-решение, с помощью которого реализуют что-то типа "приборной панели", на которой отражаются значения небольшого набора KPI верхнего уровня иерархии в онлайн-режиме. ETL-система собирает их из различных систем и сводит в дерево иерархии с инструментарием отображения в виде гистограмм, сфетофоров, графиков, циферблатов и т.п. Как только какой-то "светофор" начинает светиться не зеленым, а красным, гендир щелкает по нему мышкой и "проваливается" по иерархии KPI на более нижние уровни, где более детально отображается структура показателей, сформировавших сигнал данного "светофора". Он может увидеть подкрашенные красным, проблемы и "провалиться" в них до тех пор, пока не выявит причину на самом низовом уровне, отражаемом в системе, и не выяснит, на каком участке возникла такая проблема и характер этой проблемы. Далее он уже может поднять трубку телефона и начать принимать меры... Однако, чтобы всё подобным образом работало, нужно разработать и внедрить систему KPI. Нужно также понимать, что работать с такой системой нужно также системно. Если сразу все показатели будут гореть красным, показывая проблемы сразу везде, толку от нее будет ноль. Кроме того, по каждой выявленной проблеме крайне желательно запускать процедуру "анализа коренных причин" (RCA в Six Sigma), либо нечто ей подобное, и в обязательном порядке устранять вызвавшую причину, если эта причина носит системный характер. Таким образом, управление, ориентированное на "тушение пожаров", постепенно переориентируется на устранение потенциальных причин возникновения пожаров. Разработка системы системы KPI - весьма непростой проект, который имеет полное право на самостоятельность.

bagratОчень интересно.Что это за процессы такие-дайте пример.“А в BPMS подобное возможно” - охотно верю, а на практике как ? , как это персонал так же гибко перестраивается под новый, гибкий БП да на ходу ?Это реализуется в BPM-системах, поддерживающих версионность шаблона БП (таких сейчас подавляющее большинство). Когда вы изменяете шаблон БП, старая редакция шаблона не удаляется, а сохраняется в системе, в дополнение к прежней редакции возникает новая редакция того же самого шаблона. Каждый экземпляр БП "знает" о том, в соответствии с какой редакцией шаблона БП он исполняется. Соответственно, в системе может содержаться одновременно несколько сот экземпляров одного и того же БП, исполняющимся по 10 разным редакциям шаблона этого БП. Пользователи работают с WEB-порталом, в котором видят, какие задачи "сваливаются на их голову". :) Если БП качественно разработан, то при получении какого-либо задания каким-то пользователем, который прежде никогда его не получал, пользователь может полностью ознакомиться со всей информацией, которая связана с текущей задачей. Если его интересует, каким путем и почему эта задача к нему попала, он может открыть схему БП в соответствующей редакции (редакция открывается всегда соответствующая! - BPM-системы, как правило, имеют такой функционал) и показывает и саму схему БП, и выделяет уже пройденный маршрут одним цветом, а непройденный другим. Однако, вся эта красота будет работать только с той частью БП, которая ведется в BPMS. Длинная цепочка действий, выполняемых в ERP-системе, в BPMS будет выглядеть, скорее всего, как одно комплексное действие. Хотя, взаимодействие систем потенциально можно сделать и более "продвинутым", чтобы BPM-система отслеживала по собственной схеме БП некие фазы обработки данных в ERP-системе, но это делать весьма трудоемко, нужно смотреть, стоит ли овчинка выделки.

bagratПо п4. Вы можете привести конкретный пример по этому пункту, что это за БП такие которые так часто меняются…., и как это персонал успевает работать по новым инструкциям (их еще и создать надо). А мы вроде уже и оформили и утвердить как основу успелиЯ немного дополню ответ АБ по этому пункту.

Изменчивость БП - это очень важное их свойство, одно из ключевых в процессном управлении. Наличие постоянных изменений, оптимизирующих процесс, является, возможно, самой главной компонентой процессного подхода. В концепции TQM, в стандартах серии ISO:2000-2001 оговаривается обязательное наличие "процесса над процессами", то есть, формализованного процесса оптимизации всех остальных процессов, который вписывается в идеологию цикла PDCA (цикла Шухарта-Деминга). В российской СМК всё аутотентично западным стандартам ISO, рекомендую заглянуть в ГОСТ Р ИСО 9004-2001 "Системы менеджмента качества. Рекомендации по улучшению деятельности" и ГОСТ Р ИСО/ТО 10014-2005 "Руководство по управлению экономикой качества." В концепции Six Sigma существует аналогичный цикл, только называется иначе - циклом DMAIC, но по сути это то же самое, что PDCA. В Lean и Кайдзен вы неизбежно столкнетесь с аналогами подобных циклов и отдельных компонентов, в частности, с методами устранения "муда" для целей SMED (в JIT "STEP") - сверхбыстрой переналадки оборудования. Статистические методы управления качеством в концепциях TQM и Six Sigma предполагают регистрацию ключевых параметров качества процесса и отслеживание отклонений контролируемого параметра за пределы соответствующего количества сигм процесса (в TPS это делалось с помощью карт Шухарта). Отклонения обрабатываются разными способами, могут обрабатываться каждое (инициируется процедура RCA - выявление корреных причин), либо статистическими методами обрабатывается некая совокупность отклонений для того, чтобы выявить корреляции этих причин со всевозможными потенциальными факторами (для чего применяется специальные математические методы, к примеру, многофакторный анализ). В соответствии с идеями Деминга (его "теорией глубинных знаний") все отклонения в обязательном порядке должны классифицироваться на две основные группы - на имеющие "особую" (системную) причину и на случайные, связанные с изначальной вариативностью параметров операций, которая при этом все равно требует оценки (в "сигмах" процесса). На первых фазах еще "не устаканившийся" процесс приводят к состоянию "статистической управляемости", устраняя основную массу "особых" (системных) причин, вызывающих первую категорию отклонений. При этом зачастую в схеме БП устранятся системные ошибки, например, неучет моделью БП неких важных факторов, в результате происходит "подгонка" модели БП под то, что на самом деле работает "в реальности". После того, как процесс доведен до состояния "статистической управляемости", он получает оценку в сигмах, и переходят к постоянной работе над увеличением сигмы процесса (то есть, над уменшением неких базовых параметров, от которых зависит вариативность параметров). Это те способы, которые доминируют в Six Sigma и в TQM. Есть еще масса частных методов, которые с успехом применяются во всех процессных концепциях сразу, в частности, методов Тагути "робастной оптимизации процессов", который применялся чаще всего японцами, но базируется на тех же принципах, что и статистические методы оптимизации в TQM и Six Sigma. Всё это я говорю для того, чтобы Вы поняли, насколько важным практически во всех концепциях процессного управления считаетеся налаженность процесса оптимизирующих изменений. Один из классиков процессного управления, Майл Вейдер, одной из главных ошибок считает "Построение Системы, не обладающей необходимой гибкостью", опять же подчеркивая необходимость регулярных изменений.

Следует, однако, заметить, что в разных концепциях отношение к регулярности изменений существенно различается. Наиболее радикальное отношение высказывается в концепции Кайдзен, которая утверждает, что изменения должны быть "каждодневными". В практике Six Sigma основные циклы улучшающих изменений имеют периодичность полгода-год - это длительность "микропроектов", над которыми работают черные и зеленые пояса ("черные пояса" - это освобожденные от иных обязанностей сотрудники СМК, "зеленые пояса" - не освобожденные, но принимающие активное участие в организации проектов в цикле DMAIC).

Надеюсь, мне удалось Вас немного напугать... (к'нерес, ахпер) :). А теперь расскажу "по-человечески" о тех изменениях, которые, как правило, дают хороший результат при внедрении BPM с использованием BPMS. Сначала Вы имеете некоторую систему, которая в существенной степени управляется "сама собой", либо "никем". О том, что она из себя представляет, высшее руководство имеет очень обобщенные представления (с отфильтрованными деталями, которые на самом деле имеют важное значение). А ответственные за конкретный участок работы знают только свой участок. В конечном итоге получается, что Систему в целом не занет вообще никто. Поэтому первое, что происходит при внедрении BPM, это формализация процесса, попытка задокументировать систему. Точнее, попытк И (потому что с первого казачьего наскока задокументрировать можно только модели процессов только с содержанием в ней весьма грубых ошибок). Поэтому процессы изначально прописываются укрупненно, без детализации. Всё как работало, примерно так и продолжает работать, только в описанном состоянии, только и всего! :) Как команды подавались "голосом", так они и подаются, только в ключевых фазах в BPMS регистрируются факты подачи таких команд. Автоматизация процессов управления на этой фазе может быть очень низкой - но это стартовое состояние. Самое главное, оно позволяет начать регистрировать в BPMS информацию, которая прежде была только в головах, причем во множестве разных голов, и всегда разбитой на части, а теперь в одном месте. Как только БП запустили в BPMS на выполнение, вы начинаете фиксировать все сбои, отклонения, проблемы. И можете анализировать их статистику уже не на уровне "ощущений", а глазами глядя на статистические данные. Только получив эту, самую первую, возможность, гендир уже сможет сделать массу очень верных телодвижений по устранению системных проблем.

Далее происходит довольно долгая (если не сказать "бесконечная") фаза постепенной детализации описанных процессов. Вот для того, чтобы иметь возможность постепенно детализировать схемы БП, и нужна "сверхгибкость" BPMS, потому что детализируются те процессы, которые в ней УЖЕ ИСПОЛНЯЮТСЯ . На одном из наших заводов изначально укрупненно описанный процесс (в BPM-системе UNIFY NXJ) содержал порядка 12-15 укрупненных операций. В процессе постепенной (каждодневной!) детализации количество операций было увеличено более чем в 10 раз за три месяца - при уже запущенном в работу процессе! Такая детализация постепенно уточняет описание системы и приводит к выявлению и устранению системных проблем, возникающих локально. И опять в BPMS всё регистрируется, всё более и более детально.

К основным процессам в процессе такой детализации вы постепенно прописываете вспомогательные, которые с ними взаимодействуют. К вспомогательным - дважды вспомогательные... И так далее, пока не опишите с достаточной степенью детализации весь бизнес. Наверняка на это уйдет не один год. Но вы не будете испытывать никаких стрессов, которые могут завести бизнес в тупик и поставить его на грань выживания. Каждая модификация процесса не делает ничего революционного, она лишь описывает еще не описанное, и всё! Далее идет длительная работа над устранением ошибок в описании. Разумеется, на этой фазе вы столкнетесь с множественными расхождениями в представлениях различных руководителей о том, каким образом работает или должен работать процесс. Наверняка столкнетесь с конфликтами интересов, с попытками спихнуть ответственность за что-либо с себя и повесить ее на кого-нибудь другого (который отвечает совершенно симметричным стремлением). Вот тут уже потребуется воля гендира, на стол перед которым выкладывается видением первого, второго и третьего, гендир чешет репу и говорит "будет по-четвертому, исполняйте", и сказанное сразу вносится в схему. Если гендир при этом недооценил какие-либо потенциальные проблемы (гендиры тоже люди, которые обладают способностью ошибаться), мы получим проблемы, которые фиксируются BPMS. Можно вернуть эти проблемы гендиру, чтобы он вник в их причины и внес коррективы в ранее принятое решение, либо вставил пистон тому, кто намеренно такие проблемы создает, тихо саботируя принятое решение.

Вот этим и придется заниматься, внедряя BPM с опорой на BPMS... Этим придется заниматься долго и нудно - много лет. При этом предприятие будет ПОСТЕПЕННО устранять проблемы, что сделает оптимизацию бизнеса безболезненной для нее. Это ключевое отличие от однократного и масштабного реинжиниринга БП, которое, наверняка будет очень болезненным и которое опять же наверняка будет проведено с ошибками, которые никто не планирует устранять.

Когда вы опишете достаточно детально все БП, вы уже получите такое представление о системе, на некотором новом качественном уровне, о котором прежде даже не мечтали. С этого момента вы выйдите на новый уровень зрелости бизнеса. Но не высший... Потому что оптимизация бизнеса на этом не закончится. Вы сможете фиксировать в системе все ключевые параметры эффективности (KPI). Надо будет тщательно подумать над структурой таких показателей, над их иерархией, и когда система описывает, по меньшей мере, основные процессы, вы уже можете прикрутить к ней какое-нибудь ETL-решение и предоставить гендиру и другим разным топам возможность быстро ориентироваться в огромной совокупности текущих взаимодействий, требующих их внимания, которое на некой "приборной панели" будет красным показывать то место, которое требует их внимания. И избавит их от вмешательство в те процессы, которые прекрасно работают и без их участия.

После того, как вы получили зрелую систему KPI и регистрируете соответствующую статистику, вы можете продолжить оптимизировать модель, уже методами математической статистики выявляя системные причины отклонений таких показателей от нормы. И на этой фазе вы выловите еще целый траулер мелких системных проблем, которые не были видны "невооруженным глазом". После того, как вы проведете еще и эту работу (на нее тоже уйдет несколько лет, я полагаю), вы сможете считать все свои процессы доведенные до состояния "статистической управляемости". И с этого момента можете оценить их в сигмах и работать уже над увеличением числа сигм. А вот этим можно заниматься уже до бесконечности... :)

Извините, за объем. Но в двух словах не представляю, как это можно было сказать. :)