Нынешний финансовый кризис отрасли BPM не угрожает: ведь чтобы был кризис, надо чтобы сначала был бум, а у BPM его не было.
Этот бум призывали, называя BPM “The Next Big Thing”. Кто-то сделал на ожидание бума серьезные ставки - я имею в виду в первую очередь независимых разработчиков BPMS (”pure-plays”). Хотя и поставщики ПО широкого профиля (”stack vendors”) тоже врядли удовлетворены финансовыми результатами приобретения BPM-активов.
В России у каждого поставщика BPMS на сегодня есть по полтора проекта - один успешный, один не очень - о которых они докладывают на всех конференциях. Первая конференция по BPM в Москве прошла в 2006 году, то есть компании вкладываются в маркетинг уже минимум три года. Не густо, во всяком случае на бум не тянет точно.
Давать оценки состоянию глобального рынка не возьмусь, сошлюсь на мнение Рашид Хана. Оно интересно тем, что до недавнего времени он возглавлял компанию Ultimus, известного поставщика BPMS, а сейчас основал консалтинговую фирму. То есть он и “в теме”, и может позволить себе высказываться без оглядки на инвесторов. Рашид Хан обращает внимание на то, что отраслевые аналитики из года в год дают оценку объема рынка BPM в диапазоне от 1 до 3 миллиардов долларов и предсказывают годовой прирост в 10-20%. Даже если принять консервативную нижнюю границу в 10%, то объем рынка должен уже составлять как минимум 4 миллиарда. Но последние отчеты опять дают цифру 2 миллиарда - очевидно, обещанный рост задерживается.
Может быть пора перестать изображать оптимизм, признать существование серьезных проблем и попытаться дать ответ на три извечных русских вопроса: кто виноват, что делать и что делать с теми, кто виноват? 
Размышляя над этим, вспоминая высказывания потенциальных заказчиков, анализируя опыт выполнения проектов BPM, я нахожу следующие причины:
1. Слишком много процессных дисциплин
Учение о процессном управлении в том или ином виде существует уже десятилетия. TQM, реинжиниринг, шесть сигм, бережливое производство, BPM - в чем-то они все сходятся, но в чем-то серьезно расходятся. У каждой из этих теорий есть свои последователи, которые в лучшем случае не подозревают о существовании альтернативных подходов (я до сих пор встречаю людей, у которых представление о внедрении процессного управления сводится к “as-is” и “to-be”), а в худшем - ведут друг с другом религиозные войны.
Представим себе идеального потенциального заказчика: амбициозный директор, который заинтересовался процессным управлением. На полке у него стоит монография под названием “Реинжиниринг бизнес-процессов”. В свое время внешние консультанты за немалые деньги провели инвентаризацию бизнес процессов, схемы до сих пор лежат в шкафу. На курсах MBA ему рассказывали про шесть сигм. Теперь на конференции по BPM ему рассказывают, что с реинжинирингом вышло не очень хорошо, но теперь прошлые ошибки учтены.
Стоит ли удивляться, что у некоторых людей бизнеса в результате развилась настоящая аллергия: как только вы произносите словосочетание “бизнес-процесс”, разговор заканчивается. Тот, кто испытал на своей шкуре реинжиниринг или полную инвентаризацию бизнес-процессов компании, никогда в жизни не согласится пройти через что-либо подобное. Подробности - BPM это или что другое - его уже не интересуют: “плавали, знаем”. Я встречал таких неоднократно.
2. Подмена понятий и размывание концепции
Меня бесит, когда BPM называют “зонтичным термином”. На самом деле, BPM - это целостная концепция, в которой органично сочетается управленческая методология, специализированный софт и принципы гибкой (agile) разработки.
Но чтобы это по-настоящему прочувствовать, недостаточно прочесть статью в интернете или сходить на презентацию - необходимо своми руками выполнить хотя бы небольшой пилотный проект. А это сложно, куда проще заявить: “что вы мне рассказываете про BPM, я им 10 лет занимаюсь, мы еще в 95-м рисовали схемы процессов в IDEF0″. Таким образом, размывание концепции BPM связано с тяжелым наследием, см. п.1.
Поставщики BPM-инструментария добавляют неразберихи, подменяя понятия. Вообще, “переклеивание лэйблов” - традиционное занятие. В свое время все СУБД вдруг стали реляционными в течение одного года. Для этого не надо выпускать новые версии своих продуктов, достаточно выпустить новые версии маркетинговых брошюр. Так же и сейчас: BPM называют и рисовалку диаграмм в Visio, и примитивный документооборот, встроенный в бухгалтерскю систему.
Но послушайте! Изобретать новую аббревиатуру, чтобы подгрести под нее все то, чем в течение последних двадцати лет мы занимались в области бизнес-процессов - это, в конце концов, просто неэкономно.
3. Процессное предприятие - это утопия
Процессное управление позволяет добиться положительных финансовых результатов? Допустим. Но ведь есть масса других способов: получение преференций от государства, уклонение от налогов, манипулирование с отчетностью, использование монопольного положения, участие в коррупционных тендерах, разнообразные откаты и т.д.
Бизнесом заправляют не идеалисты, а люди прагматичные, чтобы не сказать циничные. Идеалисты в нем просто не выживают. Предположим, какие-то из перечисленных негативных явлений укоренились в окружающей экономической реальности. Можете вы себе позволить быть единственным д’Артаньяном - например, не давать откатов в тендерах, когда все ваши конкуренты их дают?
В политике бывает, что тот, кто делает правильные шаги, расплачивается за них своей популярностью, и плодами пользуется уже другой - тот, кто пришел ему на смену. BPM обещает дать компании устойчивое конкурентное преимущество, но требует для этого серьезных и долгосрочных усилий. Многие ли менеджеры готовы “пробивать” идею, которая принесет плоды возможно уже не ему? Готовы ли акционеры публичной компании одобрить такие шаги?
Получается, процессное предприятие - это “сияющий град на холме”, мечта, плохо совместимая с пороками этого несовершенного мира.
4. Для BPM всегда или еще рано, или уже поздно
На первых годах жизни компании в ней царит культ героев, и это правильно. Формализм тут может только помешать. Когда компания растет на сотни или десятки процентов в год - о каких процессах может идти речь?
Когда же компания сталкивается с серьезным кризисом, заниматься процессами уже поздно. BPM как часть антикризисных мероприятий? Крайне сомнительно; для массового сокращения персонала есть проверенный метод вульгарного “реинжиниринга”.
Конечно, между периодом бурного роста и периодом нарастающих проблем есть интервал, в котором как раз и надо бы заниматься процессами. Только многие ли на это способны? Да, “выживают только параноики”, но ведь это так утомительно - быть параноиком.
5. Слишком сложно чтобы быть практичным
Чтобы успешно практиковать BPM, компания должна обладать компетенциями в области бизнес-анализа, информационных технологий, проектного управления. Анализ и рационализация бизнес-процессов, BPMN и BPEL, веб-сервисы и SOA Governance, Web 2.0 и Agile методологиии… вас этот список не пугает?
Дополнительная сложность в том, что требуемые компетенции, если они и есть, сосредоточены в разных подразделениях. В частности, анализ и совершенствование бизнес-процессов (если мы говорим об основных процессах компании) силами одного ИТ невозможны в принципе.
С точки зрения ИТ-директора, который на практике обычно играет если не главную, то важную роль в BPM-проекте, BPM выглядит сложнее любой другой информационной технологии. Ведь самое сложное в работе с компьютерами - это работа с людьми. Только в частном случае “system-to-system BPM” - процессов полностью автоматических или с минимальным участием людей - все резко упрощается. Такие процессы характерны для банков и телекома, отсюда доминирование именно этих отраслей в успешных проектах BPM.
ИТ-директор и другие участники проекта оказываются морально не готовы к тому, что придется столь многому учиться. Исключение - компании, в культуре которых укоренился культ инноваций.
Восприятие же основной массы изменится только когда сегодняшние студенты, изучающие BPM в университетах, придут в компании на роли ИТ-специалистов, бизнес-аналитиков, функциональных менеджеров. Оптимизм внушает то, что BPM становится популярной дисциплиной в российских университетах и студенты осваивают его с настоящим энтузиазмом.
6. Слишком много новых парадигм
Когда видишь, как за BPM-проект берутся люди, находящиеся в парадигме функционального управления (оно же иерархическое, оно же традиционное), то отчетливо понимаешь: ничего не будет.
Но с другой стороны, когда вам говорят “вы должны сменить парадигму”, это напрягает. А если от вас требуют менять парадигму каждые пять лет (см. п.1) - как вы к этому отнесетесь?
Как и в п.5, либо инновации должны быть частью культуры компании, либо парадигмы будут меняться только вместе с людьми, т.е. со сменой поколений. Но последнее для нашего времени все-таки слишком медленно.
7. Невезение
Производителям BPMS не повезло дважды: сначала они попали под кризис дот-комов, теперь - под глобальный финансовый кризис. А ведь любая технология уязвима на начальной стадии своего развития - если не набрать необходимый темп развития, есть риск не набрать необходимого уровня признания рынком и не преодолеть “пропасть Мура“.
Источником инноваций в отрасли в основном являются независимые производители (”pure-plays”). Это относительно небольшие компании, существующие за счет венчурного капитала. При сегодняшнем состоянии рынка капиталов их перспективы выглядят не радужно.
8. Позиция ERP-вендоров
Мне приходилось слышать от потенциальных заказчиков: “бизнес-процессы? они у нас все в SAP”. ERP-системы - это часть тяжкого наследия (п.1), а ERP-вендоры преуспели в размывании концепции и подмене понятий (п.2). Если вам дали возможность нарисовать бизнес-процесс в eEPC, то это еще не значит, что вам дали BPM-систему.
Где происходит подмена понятий: когда вендор говорят, что его система гибкая, и ее можно настроить на ваши бизнес-процессы, они умалчивают, что это можно сделать один раз, при начальной настройке системы. ERP-система на этапе внедрения - это цементный раствор, на этапе эксплуатации - застывший бетон. ERP-системы в их нынешнем виде - это не BPM, а реинжиниринг: один раз тщательно продумали “to-be”, запустили, получили оптимальный процесс. Суть BPM - в возможности безболезненно менять бизнес-процессы, в непрерывном их усовершенствовании.
Впрочем, сейчас ситуация тут меняется - я имею в виду в первую очередь то, что делает SAP в области SOA и BPM (см. заметку и отчет на блоге Брюса Силвера). Судя по опубликованному роадмапу, скоро мы воочию увидим то, что давно предсказывают аналитики: ERP-систему на основе SOA, состыкованную с полноценной BPMS.
9. Процессы под грифом “совершенно секретно”
Люди бизнеса не любят, когда чужаки копаются в их бизнес-процессах. Не из-за опасности утечки информации - от этого можно защититься - а в основном из-за ревности.
Психологически их можно понять: представьте, что вы полжизни положили на эту компанию, знаете ее вдоль и поперек, многое сами лично придумали и организовали, и тут приходит какой-то эксперт или аналитик, да еще чего доброго в два раза вас моложе, и оценивает вас как на экзамене: вот тут процессы организованы на пятерку, а тут - на двойку. “Да что он вообще понимает! Он сам в жизни не руководил крупной компанией. И к тому же не знает специфики отрасли.” Точно так же они не любят раскрывать процессы собственному ИТ.
В глубине души они боятся, что нарушится их внутренняя гармония - вера в то, что они все устроили правильно. Если такой барьер возникает, предолеть его можно только “под угрозой расстрела” - если компания стоит перед лицом действительно серьезных проблем. Но тут мы возвращаемся к п.4: в такой ситуации обычно уже бывает поздно думать о процессах, нужны экстренные меры.
Дело обстоит лучше там, где частью культуры компании является регулярная переоценка всего и вся. “У нас неприкасаемых нет. Каждая служба в любой момент должна быть готова к внешнему аудиту ее деятельности. Кого это не устраивает, тех мы не задерживаем.” - такие слова я слышал от одного из руководителей.
10. Слишком дорого
Приличные BPMS стоят недешево. Правда, если сравнивать с общим бюджетом BPM-проекта крупной компании, то не слишком и дорого. Стратегический по масштабу проект (а BPM-проект - это стратегия) не может быть дешевым.
Но вот среднему бизнесу к топовым BPMS не подступиться. Причем это плохо для самих же вендоров BPMS. Ведь средний бизнес более активен, более восприимчив к новому, и опыт BPM мог бы накапливаться в компаниях среднего масштаба. А крупных компаний мало, и у них есть масса других возможностей (см. п.3). Вендорам стоило бы подумать о более гибких схемах лицензирования и о том, чтобы давать максимально широкий доступ к своим технологиям студентам (см. п.5).
Где-то я утрирую, но полагаю, что все перечисленные причины присутствуют в той или иной мере.
А как обстоят дела у вас? Если вы найдете время высказаться в комментариях, то совместными усилиями мы сможем составить объективную картину. А может, вообще исходная посылка неверна и с отраслью BPM на самом деле все в порядке? Или есть какая-то главная причина, которую я упустил?
Чтобы не заканчивать на пессимистической ноте, приведу цитату из интервью Гэри Рамлера:
“Я уверен, что процессы никуда не денутся. Они пережили увлечение реинжинирингом, и я уверен, переживут и технологическую путаницу. Почему? Потому что бизнес получает прибыль от продуктов и услуг, обладающими ценностью для клиентов. А эти две вещи появляются только в результате работы основательных внутренних процессов. Я думаю, на следующей стадии эволюции процессов бизнес должен осознать, что процессы являются кирпичиками системы создания ценности, которая в конечном счете ему необходима чтобы быть успешным.”
С какими бы проблемами не сталкивалась отрасль BPM, управленческая наука не изобрела ничего лучшего (есть еще проектное управление, но его область применения достаточно четко отделяется от процессного). Бизнесмены, которых амбиции и мораль заставляют выстраивать бизнес не на откатах, а “по уму”, есть и будут. Студенты дорастут до менеджерских должностей. Цены на софт упадут (сравните цены на СУБД сейчас и 10 лет назад). И тогда управление компанией без BPM будет просто невозможно себе представить.
Sure, there are serious problems with BPM which should be openly discussed. (I am going to do that also at a BPM seminar in Moscow today).
See more … http://improving-bpm-systems.blogspot.com/2009/04/re-10-reasons-why-bpm-market-doesnt.html
помоему, одной из причин малого количества bpm-проектов в россии является малое количество компаний, готовых к таким проектам;
каким бы грамотным в области bpm ни был консультант, он не поможет компании, культура управления в которой находится на низком уровне;
в таких случаях проекту bpm должен предшествовать ряд предварительных мероприятий, ориентированных на поднятие этого самого уровня культуры управления в компании
Согласен, но это было бы полбеды. Беда в том, что, во-первых, не только в России - были бы убедительные образцы на Западе, было бы легче.
А во-вторых, и прогрессивные по любым меркам компании сталкиваются с серьезными затруднениями - говорю по собственному опыту, мы с такими работали и работаем. То есть культуру надо не столько “поднимать”, сколько менять. А это непросто.
Вот например парадокс: чем лучше компания научилась управлять большими ИТ-проектами, тем сложнее ей применить BPM - см. http://bpms.ru/library/articles/bpm-charters/index.html
еще хочется подчеркнуть мысль, затронутую в данной статье, о том, что bpm можно и нужно продвигать среди компаний среднего бизнеса, ввиду его большей мобильности по сравнению с крупными компаниями;
это и накопление опыта, и лучшее соответствие результатов проекта поставленным целям, правда есть большое “но” (как раз об этом в статье и упоминается), средний бизнес не купит топовый bpm-продукт;
мы обходимся собственным решением, разрабатываемым с нуля, идем путем шишек и ссадин
По моему мнению, покупка “топового bpm-продукта” (то есть BPM suite) не является ни необходимым ни достаточным условием построения хорошей BPM системы предприятия. А если нужна практическая помощь чтобы избежать “шишек и ссадин” то об этом говорилось на информационном семинаре прошлую неделю.
Выступления можно найти на slideshare:
http://www.slideshare.net/samarin/how-to-get-bpm-working-for-your-enterprise
http://www.slideshare.net/samarin/practical-aspects-of-implementation-enterprise-bpm-systems
Thanks,
AS
Мне кажется нужно найти яркие удачные примеры внедрения бизнес-процесов на больших или средних предприятиях. Нужен *Стаханов*, который получил сверхприбыль после внедрения. Убеждают только цифры и личный пример.
Помочь может только желание быть лучше самого лучшего.
Спасибо.
Alex, а Вы много знаете ярких удачных примеров внедрения ERP? С цифрами и личным примером?
И тем не менее ERP внедряют. Потому что деваться некуда: хочешь - не хочешь, а вести учет и планировать бизнес необходимо, а ничего лучшего вроде как не изобрели. С BPM ситуация иная: тут деваться вроде есть куда. Можно подтянуть исполнительскую дисциплину, топ-менеджер может личным примером воодушевить, чтобы все как один… короче, заменить системный подход героизмом.
То есть ERP в том или ином виде или, скажем, СУБД - вещи необходимые, а BPM - премиальная. Во всяком случае, пока. А в примерах удачной реализации BPM недостатка нет.
Да Бог с вами, и ERP-то тоже далеко не все внедряют! Забудьте на минуточку об офисах в высотках. Куча предприятий а-ля “бывшая оборонка”, на котором и компы-то не у всех стоят. Ну да, возможно туда мы и не заходим, они живут в каком-то другом мире. Какой там BPM?
).
Если речь идет о России, то наши люди просто не стремятся быть первыми (ну не все, конечно, но большинство). Слишком долго они смотрели на “заграницы”, мечтая жить так же. Или хотя бы почти так же. Заметьте: не ЛУЧШЕ, а ХОТЯ БЫ… Привычка догонять укоренилась, и исподволь срабатывает до сих пор. Недавно один человек мне сказал буквально следующее: “Мы понимаем, что BPM- это очень прогрессивно, этого еще ни у кого нет. Но мы не стремимся быть первыми, нам бы элементарный учет наладить”. Ну не летают они! А если и летают, то только в мечтах и то очень недалеко (вспомнилась Чучундра, которая мечтала добраться до середины комнаты
Вы думаете, что людей пугают финансовые вложения в BPM? Скорее всего нет. Пугает ответственность. И то, что это “насовсем”. Не так что “промучаюсь пару месяцев, а потом оно само…” А то, что “это ж мне теперь постоянно надо будет так?”. Отсюда и “BPM под ключ”. Чтобы только меня самого не дергали.
Уточню: я имел в виду ERP в широком смысле слова. Т.е. включая 1С.
А по поводу отсутствия амбиций - согласен. Либо их нет, либо если есть, то какие-то уж очень краткосрочные. На проект амбиции есть, а на стратегию - нет.
согласен, именно долгосрочность внедрения bpm является одной из причин того, что его не внедряют;
проект внедрения erp: пригласили сторонних консультантов, 6-12 месяцев (или больше), epr (в том числе 1С) внедрено (пусть не идеально, но все таки)
проект внедрения bpm: пригласили сторонних консультантов, 2-6 месяцев (или больше), bpm не внедрен, процессы в первоначальном их виде описаны, но они не работают, есть отчетность для анализа узких мест процесса, есть автоматический перенос выполняемых экземпляров процесса на более новые версии, нет топов, которые будут совершенствовать процессы, когда уйдут сторонние консультанты
А как насчет следующего, более быстрого, сценария внедрения BPM?
пригласили сторонних консультантов, 2-6 месяцев (или больше) –> 2 месяца на
постоянно, а потом по мере необходимости
bpm не внедрен –> внедрен способ итеративной реализации ВРМ
процессы в первоначальном их виде описаны, но они не работают –> описание процессов является также исполняемой “программой”, которая координирует работу людей и систем
есть отчетность для анализа узких мест процесса –> необязательно на начальных этапах, т.к. существующие проблемы обычно общеизвестны
есть автоматический перенос выполняемых экземпляров процесса на более новые версии –> ну это весьма полезно
нет топов, которые будут совершенствовать процессы, когда уйдут сторонние
консультанты –> внутренняя команда обучена и натренированна как совершенствовать процессы и систему; сторонние консультатны осуществляют поддержку и систематическую проверку внутренней команды
Thanks,
AS
Александр
Абсолютно верно: 1) BPM нельзя внедрить (но можно научиться его использовать), 2) BPM - это не проект (а долгосрочная программа, состоящая из множества коротких проектов).
По-другому действовать нельзя, но действовать так сильно непривычно для заказчиков - они смотрят на BPM как на очередной проект типа внедрения ERP или CRM. Необходимо переубеждать, а это всегда сложно. Или ждать пока в массах созреет понимание.
У меня на эту тему заметка выходит в очередном номере “Директора Информационной Службы” http://www.osp.ru/cio
Nice paper..thanks a lot, dear
Anyway, this is South Korea
Занимаюсь разработкой бизнесс-процессов примерно 3-4 месяца. За это время уже успел возненавидеть БПМН и все, что с ним связано. Для меня лично и для большинства переквалифицирующихся прогаммеров это совершенно новая область. Которая программирование напоминает очень и очень отдаленно. Вся прелесть БПМН в том, (как мне видится) что там можно прогаммить в “фотошопе”. Предполагалось в последствии перелжить задачу написания бизнесс-процессов на заказчиков вообще. Но как оказалось, помимо того, что требуется уметь расставлять квадратики на мониторе, требуется знать еще целую неимоверную кучу всевозможных технологий. В итоге, за эти 3-4 месяца мы с горем пополам сделали 1 проект, в данный момент завершаем второй. Честно говоря мне за них стыдно. Ощущение как будто ты ковыряешь какую-то неповоротливую, с неимоверным количеством багов какую-то серую массу.
Несколько сумбурно написал, конечно, но я хотел на собственном примере показать, что на данный момент разработка БПМС систем требует очень серьезной квалификации, как минимум. Так же есть большие претензии к программному обеспечению БПМС систем.
Что можно сказать в утешение: лет двадцать назад примерно такая же ситуация была с СУБД. Тяжеловесные системы, жрущие уйму ресурсов и требующие совершенно новых навыков. Тяжким стоном отзывались программисты
Тем не менее, сегодняшний итог известен.
Кроме того, я бы посоветовал не хвататься за первую попавшуюся BPMS. Это между СУБД сегодня, по большому счету, разницы особой нет, а BPMS до этой стадии еще довольно долго эволюционировать.
И особенно осторожно с BPMN. Есть вендоры, которые сделали максимальным приоритетом наиболее полную полную поддержку этого стандарта. Но в результате они проигрывают в других компонентах, и в частности - в дружественности для бизнеса, что, на мой взгляд, гораздо важнее. Неудивительно, что в итоге получается то что получается.
В качестве помощи могу предложить практический опыт в реализации BPM-систем — см. http://www.slideshare.net/samarin/practical-aspects-of-implementation-enterprise-bpm-systems
Thanks,
AS
2 Gemorroj
> В итоге, за эти 3-4 месяца мы с горем пополам сделали 1 проект, в данный момент завершаем второй
Вы сами-то понимаете, что вы поставили жирный плюс в пользу BPM? Два проекта за 3-4 месяца… где Вы такое видели при традиционной разработке?
Подозреваю, что существуют неверные ожидания и оценки в отношении рынка BPM. Кто является целевой аудиторией? Любая ли организация? Если исходить из эволюционной модели развития организаций - далеко не каждая. Переход от функциональной к более эффективной процессной модели управления также выбирает и доводит до конца далеко не каждая организация. Поэтому не будет и успешным и любой проект по изменению её модели управления и внедрению BPM системы соответственно (просто не нужно). Поэтому рынок организаций, которым нужны BPM системы, очень сильно сужается вопреки оценкам. Было бы, конечно, очень интересно понять, как рассчитывается его ёмкость…
Насколько я понял, EFQM утверждает что нет ограничений на переход от функциональной модели к процессной модели. На мой вопрос о сложности такого перехода, было сказано, что, как правило, эти две модели дополняют друг-друга и процессы добавляются постепенно. Например, руководитель отдела кадров становиться ответственным и за процесс “hire-to-retain”. Что-то на подобие suduku — функциональные “сило” и процессные “туннели” должны быть взаимно согласованны
Thanks,
AS
Эти quality people - они такие, у них сложностей вообще никаких. В основном, подозреваю, по той причине, что их с их красивыми диаграммами никто не воспринимает всерьез. Они сами по себе, жизнь сама по себе. А если браться на за голое моделирование, а за исполнение (what you model is what you run), и не за вспомогательный процесс найма на работу, практически не выходящий за рамки одного “сило”, а за основной и реально кросс-функциональный процесс? Тоже “постепенно добавится”? Ну не знаю, не встречал такого
Мы обсуждали только вопрос “функциональный подход против процессный подход” — EFQM отметила улучшение результатов предприятий при использовании процессного подхода. Специалистами в “what you model is what you execute” они себя определенно не считают.
Еще было одно замечание — есть определенный интерес на Украине и Белоруссии к переходу на процессный подход и никакого интереса в России. Может мы всех распугали громадьем BPMа (которого еще никто не встречал)?
AS
Видимо мы медленно запрягаем… Хотя с наступлением кризиса определенное повышение градуса интереса пожалуй наблюдается.
Толя, ты зачем в п.3 обозвал меня циником?
Всякое совпадение с реальными личностями чисто случайное
Если серьезно, то пафос этого пункта в значительной степени направлен против временщиков, к которым ты явно не относишься.
Хотел бы продолжить Ваш список и предложить 11 причину: Отсутствие инфраструктуры, поддерживающей управление на процедурном уровне.
И это относится не только к BPM - без инфраструктуры нельзя поддерживать в адекватном состоянии базисную часть управления (бизнес-модель, процессы, учет). Все, что ни поставят в этой сфере внешние консультанты - либо упадет после их ухода, либо зарастет мхом и будет использоваться на 10%, либо ограничит инновационную оперативность предприятия.
Для преодоления отставания систем управления отечественными предприятиями, на мой взгляд, необходимо развести функции постановщика и эксплуатанта системы управления и ее Пользователя в лице Генерального директора. На предприятии должен быть специалист, со статусом заместителя Генерального директора, который отвечает за качество системы управления и ее инфраструктуру - возможно тогда внедрение ВРМ пойдет веселее.
Владимир
Согласен. Я иногда говорю, что BPM - это для тех, у кого ERP уже есть, а счастья еще нет. Если на предприятии нет нормального управленческого учета, то для BPM можно найти только ограниченное применение. Зато, с другой стороны, если на предприятии управленческий учет в интегрированной системе налажен, а планирование - нет (а это, по моему впечатлению, преобладающая картина сегодняшних внедрений ERP), то BPM будет и востребованным, и крайне эффективным - он позволит многократно повысить полезность той инфраструктуры, которую компании удалось создать. Мы сейчас делаем как раз такой проект, так что все это очень хорошо видно.
Внешние консультанты не виноваты. Классики MRP-II многократно повторяют: чего-то добиться можно только если это будет проект “Do It Yourself”. Но с какого-то момента заказчики предпочли не обращать на эти предостережения внимания, а верить в обещания консультантов “сделать все под ключ”. Того, кто сам рад обмануться, обмануть ведь не трудно.
Такой специалист вроде называется ИТ-директор. В больших корпорациях на западе сейчас появилась еще модная должность “chief process officer”. Или Вы под инфраструктурой понимаете нечто большее, чем ИТ?
Под инфраструктурой управления я понимаю все, на что опирается руководитель при подготовке, принятии, реализации, контроле и корректировки управленческого решения (действующие управленческие регламенты, практика управления в виде формализованного управленческого инструментария, информационные системы и прикладное ПО, отдельные исполнители и структурные подразделения, решающие узкоспециализированные управленческие задачи).
ИТ, безусловно, часть инфраструктуры управления, но за всю управляемую сложность, чаще всего не отвечает.
А “chief process officer” - это интересно. Спасибо.
Antoly,
I agreed with Rashid’s analysis and yours and therefore what you need is a proved methodology, combined with a powerful yet simple product delivered trough an accessible business model. As we just happened to release BizAgi Xpress, why don’t you go on, visit our web site at http://www.bizagi.com, download it (no questions asked) and experience it? It provides enterprise class functionality at very low cost!
If you found this post interesting than you should probably read Scott Francis’ view of the same problem from different angle:
http://www.bp-3.com/blogs/2008/10/six-barriers-to-bpm-adoption-in-the-enterprise/
Коллеги, я работаю в ИТ-компании. Все мои коллеги - молодые но зрелые выскокласные специалисты в ИТ и знатоки современных теорий управления - бережливое производство, 6 сигм. Некоторые имеют дипломы MBA. Сами занимаются внедрением систем у Заказчиков. И амбициозное руководство решило внедрить BPMS, тем более что уже есть задокументированные в виде моделей все процессы. Все взялись “засучив рукава” - разрабатывать сценарии, тестировать, отрабатывать замечания.
И тут пошли замечания и сопротивление.
1. Оказалось, что каждому придется в системе работать за себя, а все хотят руководить и контролировать других
2. Никто не хочет, чтобы их система подгоняла и контролировала своевременность выполнения работ, но при этом хочет, чтобы система других подгоняла
3. Линейные руководители не хотят обращать внимание на автоматические письма из системы о нарушении сроков работ исполнителями, являющимися их подчиненными сотрудниками
4. Исполнители вообще против, чтобы им кто-либо устанавливал сроки, которые надо соблюдать
5. Никто не хочет соблюдать схему процесса, даже содержащую все необходимые вариации. Каждый считает своим долгом придумать свое исключение из утвержденного регламента - какие то шаги хотят пропускать, какие то добавлять, повторять или менять местами
6. Никто не задумывается, что с документами процесса надо работать аккуратнее, что нельзя все время добавлять новые версии одного документа вместо исправления в документе, присоединенном к процессу
7. Никто не хочет обучаться системе, а хотят ей сразу пользоваться. А потом удивляются, что не понимают, что от них хочет система
8. Никто не хочет читать сообщение на экране с подробным описанием что нужно делать на данном шаге процесса, а лепят не думая первое попавшееся в списке действие и продолжают процесс. Потом удивляются - куда все пропало и не понимают, где сейчас задача?
9. Никто не хочет пользоваться еще одной “дополнительной” корпоративной системой, хотя им вовсе не требуется вводить логин и пароль
10. Наровят по старинке дублировать процесс по электронной почте…
Хоть мы и преодолели часть проблем:
- Выбрали недорогую приличную программную платформу
- Имеем опыт по реинжинирингу предприятий Заказчика
- Имеем детальные описания собственных бизнес-процессов и никто не скрывает свои процессы
- “частью культуры компании является регулярная переоценка всего и вся. - У нас неприкасаемых нет. Каждая служба в любой момент должна быть готова к внешнему аудиту ее деятельности. Кого это не устраивает, тех мы не задерживаем.”
НО я вижу, что
-”Бизнесом заправляют не идеалисты, а люди прагматичные, чтобы не сказать циничные. ”
-”Нет культа инноваций.”
-”Не готовы к смене парадигмы управления”
-”В глубине души они боятся, что нарушится их внутренняя гармония” - когда можно запросто нарушить все правила и регламенты, если что-то срочно надо сделать. При этом совершенно не обязательно задокументировать изменение регламенте или модели процесса или еще где то
- Любой записанный регламент на следующий день устаревает, поэтому регламенты пишут для галочки, а не для соблюдения и не дай бог контроля
- каждый исполнитель по своему понимает один и тот же процесс и не хочет добровольно работать по единым правилам
Вот я сижу и думаю, чем это вызвано и как с этим бороться? Руководство заняло выжидательную позицию…
Неужели опять ждать “смену поколений”?
Одно из направлений выхода из тупика:
- некоторые процессы действительно могут иметь много вариаций и перекладывать на WF технологию их не целесообразно, т.к. устояться они не смогут никогда
- при такой вариативности процесса нужно исключать детализацию и сводить все к нескольким крупным шагам, статус выполнения которых поможет контролировать весь процесс
Поддерживаю последнее предложение. Чрезмерная детализация - это распространенная детская болезнь управления бизнес-процессами. Про это мой паттерн “микроменеджмент”. Некоторые обзывают это ругательным словом “тэйлоризм”.
Отчасти тут виновато слабое владение техникой BPM: оркестровки недостаточно, надо владеть межпроцессным взаимодействием, см. паттерн “внутренний заказ” и заметку “Межпроцессное взаимодействие через данные”. Например, люди путают use-case со схемой процесса и пытаются запрограммировать “процесс продаж”. Если бизнес и можно “запрограммировать”, то только многопоточной программой, т.е. сетью взаимодействующих друг с другом процессов. За этим добро пожаловать на http://bpmntraining.ru
Но иногда нужно прибегать не к технике, а к управленческим решениям типа: “Сотрудники подразделения X не нуждаются в регламентации их действий? Очень хорошо; регламентация и поддержка ее системой - это помощь, а не обуза. Тогда пусть будет так: устанавливаем SLA (соглашение об уровне сервиса) для всех подпроцессов, за которые вы отвечаете в рамках сквозных процессов компании, и систему наказаний/поощрений, привязанные к этим SLA. Крутитесь как хотите.”
Простой пример: у многих организациях проблемой является такая элементарная казалось бы вещь, как выставление счетов клиентам. Причина: бухгалтерия или финансисты считают своей основной деятельностью не это, а сдачу баланса или контроль бюджета. Чтобы это исправить, устанавливаем для них SLA: срок подготовки счета и процент ошибок. И/или интегральный: срок оплаты счета. И все! Никакой регламентации внутренностей этой процедуры: кому назначается задача, откуда берут данные, кто готовит - кто проверяет и т.п.
Это, а не детальная регламентация выписки счета, и есть настоящий BPM.
Я отношу себя к IT директорам, которые уверены категорически в том,что соединение BPM и ERP необходимо и давно назрело там где ERP успешно эксплуатируется почти в полном обьеме.В этом направлении работа уже ведется целенаправлено. Эксплуатация ERP сопряжена с большими трудностями когда персонал управления не считает необходимым соблюдать установленные регламенты взаимодействия в процессе пользования ERP. Оказывается привычным найти виноватого (в другом подразделении) нежели сделать анализ причин допущенных потерь на основе несоблюдения регламентов. Хорошо бы иметь какой нибудь документ описывающий практику процессного управления для вправления мозгов представителям фин,эконом и производственного менеджмента.Ну например не совсем ясен орг. механизм взаимодействия “хозяев” бизнеc-процессов и начальников отдельных производств на предприятии…..и т.д
Очень верно подмечено: ERP система не обеспечивает перехода на процессное управление, она прекрасно уживается с функциональным. Поиск виноватого в соседнем подразделении - это безошибочный симптом функционального управления.
В отечественной литературе принят термин “владелец процесса”.
Организационный механизм как мне кажется тут очень простой: если речь идет об основных, сквозных, кросс-функциональных процессах, то владелец процесса должен обладать рангом, который позволяет ему “обломать” любого, кто встанет поперек процесса. Включая руководителей функциональных направлений. Возможно, в особенно запущенных случаях, с помощью первого лица. “Обломать” означает не назначить плохишем, а договориться на “законодательном” уровне.
Второй ключевой момент: владельцем должен быть человек кровно (по должности) заинтересованный в результате процесса. Поэтому, например, владельцем процесса “от обращения до коммерческого предложения” должен быть зам.генерального по продажам, а процесса “от идеи до продукта” - директор по развитию бизнеса, а не начальник отдела дизайна.
Спасибо за отклик.Ранги Владельцев процесса и все прочее-это само-собой. Но а если владельцев несколько (направления сбыта) а функц подразделение одно (производство), через которые каждый владелец “бульдозером” проталкивает свое ?.Следовательно тут как обычно должно работать планирование ERP (в том числе и календарное)+ перерасчет приоритетов (это функция не продавливаения, а оперативной работы ЕРП по перерасчету пропускной способности центра работы (функц подразделения). Опять получается что-то похожее на централизованный контроль ресурсов на межцеховом уровне (ПДО) и соответственно на внутрицеховом (диспетч бюро).Поэтому я и задал вопрос о практике процессного управления, иными словами о практических наработках в регламентах взаимодействия владельцев БП и функционалов на производстве. Разумеется практик много из других областей, к примеру регламент распределение полномочий в экипаже между тем кто ведет к цели и на определенном этапе передает права тому кто работает по цели и затем возвращает полученные полномочия…..и т.д. Но хотелось бы что либо из бизнес-практики.
На мой взгляд, выход один. Хоть в теории, хоть на практике: договариваться на уровне регламента, а не на уровне оперативного управления конкретными заказами. Если есть несколько продуктовых направлений, замыкающихся на производстве, которое является узким местом, то один раз надо договориться о правилах игры: по какому алгоритму и в соответствии с какими приоритетами планируются производственные ресурсы.
В ситуации нескольких направлений сбыта не уверен что должно быть несколько владельцев процесса, я бы рекомендовал отдать их в одни руки.
И еще: вообще-то ситуация, в которой производственный мощности являются ограничителем - это особенность переходного периода. На зрелом рынке ограничителем почти на 100% является рынок: произвести-то произведем, а вот продать… Соответственно, если спрос такой, что мы не можем его удовлетворить, то надо не замыкаться на оптимизации ресурсов, а искать возможности для расширения. Хотя я понимаю, что советы легко давать…
Анатолий, спасибо за статью.
Мы работаем в государственной компании, где конечный продукт не так очевиден, как в коммерческих структурах. Автоматизации управления бизнес-процессами нет, есть только описание, давшееся “великой кровью”. Та же проблема владельцы-участники, а тут реализуется закон Мерфи: если за результат отвечают несколько человек, то, в конце концов, оказывается, что никто ни за что отвечает. Автоматизацию планируем, а стоит ли?