The current financial crisis isn’t a threat for BPM because there must be a boom before to talk about a crisis and there were no boom in BPM.
Some people anticipated the boom by calling BPM “The Next Big Thing”. Pure-play BPMS vendors have made big bids on the boom. The stack vendors aquired BPM assets.
In Russia, every BPMS vendor now has about one and a half BPM project - one successful and one decent - and shows them at every event. The first BPM conference in Moscow held in 2006 so companies invest into BPM marketing minimum for three years now. The results aren’t very impressive; not a boom anyway.
Instead of assesing the global market let me refer to the point made by Rashid Khan. It has special value because until recently he headed a well-known BPMS vendor Ultimus, and now owns a BPM consultancy firm. That is, he knows the matter from inside and at the same time he can afford speaking freely. Rashid Khan drew attention to the fact that year after year industry analysts assess the BPM market volume at 1-3 bn dollars range and predict annual growth of 10-20%. Even with 10% the market should be at least at 4 bn now. But recent reports still give the figure 2 billion - apparently the promised growth is yet to come.
Maybe it’s time to stop portraying optimism, admit the serious problems and try to answer three everlasting Russian question: who should be blamed, what to do and what to do with those who should be blamed? 
Recalling discussions that I had with potential customers, analyzing BPM projects experience, I came to the following reasons:
1. The legacy of process disciplines
Process management exists in one form or another for decades. TQM, reengineering, Six Sigma, Lean manufacturing, BPM - they agree on certain points yet serously diverge on others. Each of these theories have followers who are unaware of alternative approaches (I still meet people who only view process management through “as-is” and “to-be”) or are involved into holy wars with other camps.
Imagine the ideal prospect: an ambitious director interested in process management. He has a book entitled “Business Process Reengineering” on the shelf. Some time ago external consultants conducted an inventory of business processes and resulting process diagrames can be found in the drawers. The MBA courses told him about Six Sigma. Now he hears at BPM conference that there were some issues in reengineering but now measures are taken.
Is it any wonder that some business people got a kind of allergy: at the moment you say “business process” the conversation ends. Anyone who passed through reengineering or complete business process inventory project will never agree to go through something like this again. He is not interested in details - is it BPM or whatever: “thank you, been there”. I have observed such reaction many times.
2. Concept erosion and terms substitution
It drives me mad when BPM is called an “umbrella term”. In fact, BPM is a holistic concept combining management methodology, dedicated software tools and agile development principles.
Yet to develop a true BPM understanding it’s not enough to read some articles or view some presentations, you should put hands at least on a small pilot project. It’s much easier to say instead: “don’t you tell me about BPM, I’m doing it for more than 10 years, we were drawing IDEF0 process diagrams back in 1995″. This is how the diversity of process disciplines (see point 1) leads to concept erosion.
And software vendors add confusion by substituting terms. Relabelling is an old tradition: at the time, all DBMS became relational in a year term. You don’t need to release a new version of your product, it’s enough to update marketing brochures. Now a Visio plugin and a primitive workflow built into accounting package both carry the BPM label.
But come on! Inventing a new term just to cover all process techniques of the last twenty years - isn’t it a silly game?
3. A process-driven enterprise is an utopia
Let’s assume that process management produces positive financial results. But there are lots of other ways: receiving preferences from the state, tax evasion, tampering with records, the using a monopoly, the corrupt tenders etc.
Business men are pragmatics, not to say cynical. Idealists simply don’t survive. Suppose some of the mentioned bad things are rooted in the economic realities. Can you afford being the one who don’t give bribes in tenders when all competitors do?
It happens in politics that the man making the right moves looses his popularity and the one coming after him gathers the benefits. BPM promises durable competitive advantage but it requires serious and long-term efforts. How many top managers will push the idea which probably will bring payoff only after them? Will the shareholders of a public company approve such moves?
So a process-driven enterprise is like a “shining city on a hill” - a dream hardly compatible with this imperfect world.
4. It’s always either too early or too late
During the first years of company’s history there is a cult of heroes, and rightly so. The formalism maybe harmfull. There is no room for processes when a company grows to hundreds or tens of percent per year.
But when the company is facing a serious crisis, it’s too late to deal with processes. BPM as a part of anti-crisis measures? It’s very doubtful - a vulgar “reengineering” is a proven method for massive labor force reductions.
Of course there is an interval betwen the rapid growth period and a period of approaching crisis and this is precisely the time to engage processes mangement. But are there many able to do so? Yes, “only the paranoid survive”, but it’s so boring to be paranoid.
5. Too complicated to be practical
To successfully practice BPM a company must have expertise in business analysis, information technologies, project management. Process modeling and optimization, BPMN and BPEL, Web services and SOA Governance, Web 2.0 and Agile methodology… isn’t it frightening?
To make things worse, even if the required competences exist they are posessed by different departments. Process analysis in particular can’t be done by IT only if we are talking about core processes of the company. From the point of view of CIO who usually plays significant if not the major role in a BPM project, BPM looks more complicated than any other information technology. When working with computers the most difficult part is working with people indeed. Only when you deal with a special case “system-to-system BPM” - totally automatic processes or processes with minimal human participation - BPM gets simlified dramatically. Such processes are typical in banking and telecom hence these industries prevail in BPM success stories.
CIOs and other project participants are not ready to learn that much. The exception are company that made innovations cult part of their culture.
Others will change perception only when today’s students learning BPM at universities will become IT specialists, business analysts, functional managers. The good new is that BPM became a popular discipline in Russian universities.
6. Another paradigm shift
When a BPM project is conducted by the people with pure functional thinking it’s absolutely clear: nothing will happen.
On the other hand it’s a stress when someone request that you to change the paradigm. And what if a paradigm shift happens every five years (see point 1) - will you accept that?
As in point 5, either constant innovation is a part of company’s culture or a paradigm change will happen only with the change of generations. But the latter is way too slow.
7. Bad luck
BPMS vendors suffered twice: first from dot-com crash and now from the global crisis. Any technology is vulnerable at the initial stage of its development - if you do not gain the required pace, there is a risk of not obtaining the necessary level of market acceptance and fall into “Moore’s Chasm“.
Innovations in BPM mostly come from pure-play vendors. They are relatively small companies depending on a venture capital and their prospects aren’t shining with the current state of capital markets.
8. ERP vendors position
I have heard from prospects: “Business Processes? We have them all in SAP”. ERP systems are part of legacy (see point 1) and ERP vendors have succeeded in substituting terms and erosing concepts (point 2). If you are able to model business processes with eEPC it does not mean that you have a BPM system.
The substitution happens when a vendors assures that his system is flexible and can be configured to your business processes. They don’t mention that it can be done only once at initial configuration of the system. A ERP system at deployment is like cement slurry while later on it’s a block of concrete. Current ERP systems follow reengineering, not BPM: design “to-be” thoroughly, implement it in the software and enjoy running the optimal process. The essence of BPM is the ability to change business processes freely and to improve them on permanent basis.
The situation is changing - meaning what SAP is currently doing at SOA and BPM (see the note and the whitepaper at Bruce Silver’s blog). According to SAP roadmap we are now close to see what has been predicted by analists years ago: a fully SOA-based and BPMS-aligned ERP system.
9. Business processes are the top secret
Business people don’t like strangers looking at their processes. Not by security reasons mostly but because of jealousy.
Imagine that you’ve spent half of your life on this company, you know it inside out, many things are done with your personal efforts. And here comes some expert or analyst, half your age, to assess you as in the exam: this process is perfect and this one is bad. “What does he know, he never led a major company in his life! Besides he doesn’t know our industry.” By the same reasons they don’t like to disclose processes even to their own IT.
They fear that it may break the internal harmony - their belief that everything is well-arranged. If this is the case then it can be overcome only by a gun at his head - if the company faces really tough problems. But then we go back to point 4: it’s usually too late to think about processes.
There is another way of thinking: for some companies regular reassessments is part of the culture. “There is no untouchables here. Any department should be ready for external audit at any time. Take it or leave.” - the words I once heard from a top manager.
10. BPMS are too expensive
Well-rated BPMS aren’t cheap. They aren’t expensive either if compared with a total budget of large company’s BPM project. Strategic project (and BPM is a strategy) can’t be cheap anyway.
But the price is prohibitive for mid-size businesses. And it’s bad for BPMS vendors themselves. The mid-size business is more agile, more open to innovations so BPM could accumulate the practices developed by them. Large companies are few and they have lots of other options (see point 3). BPMS vendor should think about more flexible licensing and about granting free access to their technologies for universities (see point 5).
Of course I exaggerated a little yet I believe that all the above reasons are present at some degree.
And what’s the situation at your countries - in Europe, Japan, South Africa, Brazil, in the US, in India, in Australia etc.? (I’m referring to the visitors map that was recently added to the blog.) I’d greatly appreciate your comments. Maybe the initial thesis is badly wrong and everything is fine with BPM industry? Or did I miss the main reasons?
Not to end at pessimistic note let me cite from Gary Rummler’s interview to Gartner:
I am convinced “process” is here to stay. It has already survived the “re-engineering” fad, and I’m sure will survive the technology confusion. Why? Because businesses need valued products and services, leading to profits. And those two things come about only as the result of sound internal work processes. I think the next phase in the evolution of process is the recognition by business that process is the building block of the value creation system required for their ultimate success.
Whatever problems the BPM industry is facing, the management science did not invent anything better (there is also project management but it’s another domain). There are and will be the men with ambitions and morale forcing them to build a business not on corruption but on innovations. Today’s students will grow to managerial positions. Software prices will go down (just compare DBMS prices today and 10 years ago). And some day it’d be impossible to manage a company without 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% является рынок: произвести-то произведем, а вот продать… Соответственно, если спрос такой, что мы не можем его удовлетворить, то надо не замыкаться на оптимизации ресурсов, а искать возможности для расширения. Хотя я понимаю, что советы легко давать…
Анатолий, спасибо за статью.
Мы работаем в государственной компании, где конечный продукт не так очевиден, как в коммерческих структурах. Автоматизации управления бизнес-процессами нет, есть только описание, давшееся “великой кровью”. Та же проблема владельцы-участники, а тут реализуется закон Мерфи: если за результат отвечают несколько человек, то, в конце концов, оказывается, что никто ни за что отвечает. Автоматизацию планируем, а стоит ли?