Adaptive Case Management was one of the most discussed BPM topics in 2010. It transformed from fuzzy marketing noise into a more or less consistent concept over the past year.
Why “more or less”? Because even the authors of “Mastering the Unpredictable” - probably the most authoritative book on ACM to date - say in the preface that there is no consensus among them, so the book in essence is a collection of articles. Nevertheless there are more similarities than differences in their positions, hence the consistent concept.
Positive Side of ACM
ACM extends the idea of process management into areas that were tough so far: processes a) rapidly changing and b) essentially unpredictable.
Re-engineering once emerged as the idea of managing business via processes that were perceived as once yet very carefully planned procedured. Life has shown the limited applicability of this concept. It turned out that end-to-end and cross-functional business processes - that is, processes presenting the greatest value in terms of bottomline figures - are a) too complicated to program them in one iteration, and b) changing more rapidly than we are able to analyze them by traditional methods.
As soon as these concerns where perceived BPM appeared in its current form - as a discipline that combines managing business by processes and managing processes themselves i.e. their execution, analysis and optimization within continuous loop. Executable process diagrams improved communications between business and IT opening the way to deal with complex processes; rapid prototyping via BPMS and agile project implementation allowed rapid business processes changes.
Exactly how rapid? We have reached a three-week cycle in our projects which I believe is a good result taking into account the inevitable bureaucracy of release management, testing and production system upgrade control.
But what if this is not enough - if changes to the process should be introduced even faster? Or more likely if a process is so compicated that we repeatedly find that some transition or activity is missing in the diagram?
And here is the final argument in favor of ACM: what if the process is fundamentally unpredictable? Examples: a court case, the history of a medical treatment or technical support dealing with user’s issue. You can’t plan activities here because tomorrow will bring new actions taken by the opposing party at trial or patient’s new test results. It’s even hard to call it a process because process implies repetition, yet no two instances of these “processes” are identical.
These are standard ACM examples. I would also add the no man’s zone between processes and projects e.g. construction work. In a sense, construction of a house is a process because it consists of simiar activities. But at the same time, no construction work goes without troubles and complications which make each object a unique project.
Or let’s consider a marketing event: there is a template indeed but each particular event is peculiar. Same for new product development… there are many such half-projects/half-processes in every company.
What Shall We Do With Unpredictable Processes
If you can’t foresee then act according to the situation. We must give user the ability to plan further actions for himself, his colleagues and subordinates “on the fly”, as the case unfolds.
Luckily the user in such processes is not an ordinary homo sapience but so called knowledge worker. A doctor (recalling House M.D.), support engineer or construction manager - any of them could write on a business card:
John Smith
Resolve issues.
These are people trained to solve problems and paid for this job.
How the problem of volatile and unpredictable processes was approached so far:
1. By editing process scheme by business users on the fly.
For example Fujitsu Interstage BPM lets authorized users edit the schema of a particular process instance right in a browser. And even more: the modified scheme can be later converted into a new version of the process template. But it turned out to be too complicated - users simply don’t use this functionalty. Keith Swenson says on the matter: “Creating an activity at runtime needs to be as easy as sending email message; otherwise, the knowledge worker will send email instead.”
2. By ignoring the problem: there is software automating case work but it doesn’t operate in terms of processes.
For example you can create a folder in the ECM for each case and upload documents, attach tasks and notes. Or you can treat a case as a project and draw a Gantt chart. But both options won’t give process monitoring and analysis and most importantly - the knowledge of what tasks a particular type of cases consists of will not be accumulated and reused.
ACM inherits BPMS approach to process execution, monitoring and analysis but replaces “hard” templates with “soft”: ACM template doesn’t dictate what should be done but rather prompts what the user could do in current situation. The user may reject these clues and pave his own way. He may use more than one template or instantiate a case from scratch and not use any template.
Graphical process diagram is thrown away and replaced by a tasks list (tasks may be nested). Apart from the tasks list a template defines the data structure: entities, attributes, relationships.
There is no more business analysts and business users: it’s assumed that users create templates themselves and organize them into a library, thus making available to others.
So far so good but I have some concerns about this proposal.
Concern 1: Technology Instead of Methodology?
ACM advocates (or maybe only the most radical only) seem to believe that more advanced technology is all what organizations need to become more efficient: BPMS is outdated but ACM is the solution.
I don’t know… maybe I’m too unlucky but the business people that I meet are indifferent to technology, at best. Techies are speaking about how a new technology works but business people are only interested in what they will get. Productivity increase and processes transparency sound good but how will they affect the bottomline figures?
The bottomline result of a BPM initiative depends on two things: 1) quality of proposed solutions - how efficient is it in managing and optimizing processes and 2) what process was selected for the initiative. Typically, an organization has a small number of processes or just one process which is a bottleneck. Improvements in this process directly affect the company totals while any other improvements affect them at a minimal degree.
If your BPM consultant is professional enough then the first component is secured. But the problem is that the second component of success is beyond his responsibility.
And as a matter of fact, it’s beyond anyone’s responsibility. Business consultants generally know what to do (which processes to deal with) but they have little knowledge of the process technology. BPM consultants, by contrast, know how to do, but don’t have a clear vision of what to do. No system (BPM system is no exception) can establish the goals for itself - it can only be done at super-system level.
After recognizing that there is a competence gap some time ago, we developed the value chain analysis and productivity gap identefication methods to be applied before the BPM project starts. The project takes about a month and results in clear vision of where the BPM initiative should be targeted for best results and what these results shall be.
Getting back to the ACM: it seems that it discards process methodology along with process diagrams. Process analysis skills and process professionals are not needed any more because knowledge workers are so knowledgeable that they know how to do the job better than anyone else.
Maybe they do but let me ask: better for whom - for the company or for themselves?
I am afraid that orientation to the customer doesn’t come automatically. I’m afraid that knowledge workers as well as clerks engaged in routine work tend to create comfort zone for themselves rather than clients. I believe there is still much to be done in process methodology and promising new ideas - e.g. the Outside-In approach - have yet to become common practice.
ACM proponents criticize the “process bureaucracy” - business processes change approvals and other regulations. Bureaucracy is certainly bad… but it’s even worse without it. I don’t believe in empowerment as much as ACM people do and I don’t trust that knowledge workers will self-organize and the library of case templates and business rules will emerge magically. In my opinion, this is utopia. There must be strong leadership and process professionals trained to analyze company’s activities in terms of benefit to the customer, quality and cost.
In his last interview to Gartner analysts process guru Gary Rammler criticized BPM for the lack of business context:
“I think there is only one critical condition for success that must exist - and that is the existence of a critical business issue (CBI) in the client organization. If there is no CBI (hard to believe) or management is in deep denial as to the existence of one, then serious, transforming BPM is not going to happen. Period. There may be misleading “demonstrations” and “concept tests,” but nothing of substance will happen. How can it? Serious BPM costs money, takes time, and can upset a lot of apple carts, and you can’t do that without an equally serious business case. I guess you could argue that a second condition - or factor - is that the internal BPM practitioner is about 70% a smart business person and 30% a BPM expert. Because the key to their success is going to be finding the critical business issue, understanding how BPM can address it, and then convincing top management to make the investment. I guess those are the two conditions: an opportunity and somebody capable of exploiting that opportunity.”
I’m afraid that neglect of a process methodology in ACM will result in ignoring this promising technology by business.
Concern 2: No Programmers?
ACM assumes that not only business analysts are not needed but programmers as well.
Sure it would be great. BPMS vendors try to reduce the need of programmers in business process implementation, too.
Reducing is OK, but eliminating them completely?
Simply replacing the process diagram with the task list probably isn’t enough because there still are:
1. Process architecture.
When dealing with process problem the most difficult is to figure out how much processes are there and how do they interact with each other - for an example, please refer to my “Star Wars” diagram. If you did that then the remaining job - internal process orchestration - is no difficulty. If not then whatever you do with rectangles and diamonds within the process, it won’t work well.
Cases are no exception - one have to set up the architecture first. And I don’t believe that a business user without analytical mindset and not trained in solving such problems will do the job. And without that, there will be chaos instead of case management system.
2. Data architecture.
ACM advocates stress the critical importance of data constituing the case context. Arguably, for BPMS process is primary interest and data is secondary while for ACM it’s vice versa.
I do not agree with this - in my view, the process is a combination of the model visualized in a diagram, structured data (process table in the database) and unstructured documents (process folder in ECM) where all parts are equally important.
But anyway - they recommend first and foremost to determine the nomenclature and structure of the entities in your problem. Excuse me for asking, but who will do the job - a business user?
Once again: I don’t buy it! Data structures analysis and design has been and remains a task for trained professionals. Assign it to an amateur and you’ll get data bazaar instead of data base, for sure. Something like what they create with Excel.
3. Integration with enterprise systems.
Well, everyone seem to agree that this will require professionals.
So where did we come? To bureaucracy once again, this time the IT bureaucracy. It’s evil but inevitable eveil because the chaos is worse.
Concern 3: Two Process System?
Here is the question - how many process management systems do we need (assuming that cases are processes, too): two (BPMS and ACM) or one? And if one, how shall it be developed: by adding ACM functionality into BPMS or by solving all range of process problems with the ACM?
ACM proponents (well, at least some of them) position it as a separate system - they want to differentiate ACM from BPMS technology.
They argue that BPMS tries to “program” business but this is impossible in principle when dealing with unpredictable processes. Therefore BPMS is no good and we need a different system - ACM.
It reminds me something… got it: a new TV set commercial! “Just look at these bright colors and vivid images! Did you ever see something like this on your old TV?” - Of course I didn’t… But wait! Am I watching your commercial and see these bright colors and vivid images right on my old TV set?
Same here: of course, unpredictable processes can’t be programmed by a stupid linear workflow. ACM proposes more advanced way to program them, but still it’s programming. And who said that BPMS can execute only stupid linear worflows?
BPM allows to model much, much more than linear workflows. Citing Scott Francis -
“The BPM platforms that I’ve worked with are Turing Complete. Meaning, within the context of the BPM platform, I can “program” anything another software program can do.”
For example, one can model a state machine in BPMN which is presumably the most adequate representation of a case. Besides there are ad-hoc sub-processes that allow a user to choose which tasks to schedule for a particular process instance. The combination of a state machine and ad-hoc sub-processes serving transitions between the states produces something quite similar to the case.
Apart from that, stay away from micromanagement or unpredictability will hunt you everywhere.
Existing BPMS lack the ability to add a new task to the ad-hoc subprocess by one click (remember: it shouldn’t be more difficult than sending e-mail). But it seems to be fairly easy to implement. Not harder than BPMN transactions compensation, anyway.
And there is also “delegation” and “notes” functionality in the BPMS which help making a process less rigid, too.
Some ACM supporters believe that existing BPMS with their process diagrams are outdated - arguably, if ACM can manage unpredictable process then it’ll be able to cope with traditional processes for sure. But the majority seems to recognize that both management of traditional and unpredictable processes are vital.
Besides, there are processes that can be partially modelled but some other parts should be managed as cases. For example, a medical treatment is a typical case but specific test is a process that can be well-defined. This is the argument for a single system able to manage traditional predictable processes, cases and arbitrary combinations of both. And chances are that this system will be developed on the basis of existing BPMS.
Such ACM-enabled BPMS would provide some additional bonuses not mentioned above:
Bonus 1: BPM During All Stages of the Organization Lifecycle
Applicability of BPM is limited today even in regard to predictable processes: small companies simply can’t afford a business analyst and consequently BPM. This mines a future problem: with the company growth the process problems will pile up until falling down one day.
ACM-enabled BPMS would be a great solution to the problem: a small company or startup may work with cases only initially and then, as it grows, the organization structure develops and more clerks coming, a company will be able to transform seamlessly the patterns accumulated in cases into formally determined process diagram, optionally preserving the desired amount of unpredictability.
For the BPMS vendors it’s an opportunity to enter the market of small and medium-sized companies by offering a product falling into office automation category, not a heavy-weight enterprise platform as today. Support of cloud computing would additionally contributed to the success indeed.
Bonus 2: Artificial Intelligence
I do not trust that business users are willing and able to organize a library of template cases. I believe it’ll end with something similar to a bunch of Excel files. How many people are using templates in Microsoft Word, by the way? It’s a nice and usefull thing yet nobody cares.
More promising for me is the idea of implementing elements of artificial intelligence in ACM:
- To start small, a simple advisor can be implemented like the one at online bookstores saying “people buying this book also bought…”.
- More sophisticated implementation may take case data into account. For example a tech support case may suggest one tasks set or another depending on the service level of the current customer.
In essence, the system treats the whole set of case instances of a certain type as a mega-template.
Automatic analysis of the mega-template can be supplemented with manual ratings so that the user would receive not just a plain list of tasks that were performed at the similar situation but the list marked with icons saying e.g. which tasks are recommended.
Conclusion: Thank you!
ACM enthusiasts are doing the great job: they investigate the possibility of expanding the process management into previously inaccessible areas. Sincere thans for this!
Marketing considerations force them to differentiate from “close relatives” BPMS and ECM and to position ACM as an independent class of software. It seems to me that this is irrational both from technology and methodology perspective and it’s unlikely to succeed.
There was a similar story in IT history. Once relational databases have become mainstream a number of works appeared, calling further: post-relational database, semantic databases, non-first-normal-form databases, XML databases… They contained generally fair criticisms of certain aspects of relational database technology. But relational databases proved to have solid potential for evolution: missing functionalities were implemented one way or another, thereby putting alternatives into niche areas.
So here is my prediction for ACM: it won’t become a new paradigm but a new BPM feature that will expands its applicability significantly.
Anatoly,
Thanks for your analysis and for not doing away with ACM as being fully unrelated to process as seems to be the recent fashion. Your view of the artificial fragmentation of ECM, ACM, and the like is also highly appreciated because at ISIS Papyrus we have advocated this for roughly a decade now, just to be frowned upon by analysts and integrators because it’s beyond their understanding what our customers benefit from.
Best,
Michael
Great post! The description of ACM is very good, one of the best I have seen.
However, you limit yourself because you consider the only the uses of ACM that are consistent with BPM. That is why you end up concluding that ACM will always be a feature of BPM. You are missing the uses of ACM that have nothing to do with BPM.
How about project management? People use project management software to run business processes. Will project management software become a feature of BPM? In many ways, project management software is closer to BPM than ACM. Both BPM and PM deal with predictable processes. Why is it, then, that people are not arguing that PM software will merge with BPM in the future?
See my detailed discussion at:
http://social-biz.org/2011/01/22/acm-feature-or-paradigm/
My conclusion is that ACM will really become a part of Social Business Software (a.k.a. Enterprise Social Software) not BPM. Imagine “Linked-In” with collaborative planning features. That is the kind of software that Dr. House would use (if he ever actually did any work). A doctor will never use BPM — no matter how many ACM features it has. But why are we even asking this question? What made us think that knowledge workers would use BPM in the first place? The only reason one asks if ACM and BPM are the same, is if one started with that assumption in the first place.
Alexander Samarin contributed to the discussion but didn’t give a link. Doing it for him:
http://improving-bpm-systems.blogspot.com/2011/01/contribution-to-acm-feature-or-paradigm.html
Keith
Thank you for detailed and thoughtfull analysis.
I guess some of my arguments weren’t expressed good enough.
1. I believe it’s inefficient to manage processes and cases separately because a) there are “things” that are semi-process/semi-cases like tech support example above and b) there are “things” that very likely will mutate from cases to processes when the company matured.
2. In order to manage cases efficiently we must classify them. E.g. in tech support scenario there are tickets, bugs, builds, QA runs, releases, upgrades etc. This is what I call process architecture. If not treated with due respect, one will end up with a terrible mess of bugs inside tickets, different names for similar bug cases used by different users etc.
3. About data architecture: of course there are corporate applications, databases etc. But anyway: as soon as one decided to manage cases (or processes) somewhere not within these systems, he will have to define case entities, their attributes and relations between entities. Probably there will be non-case entities, too. This is what I call data architecture. Without due respect, one will end up with duplicate data and other mess.
Dana Khoyi writes at p.137 of “Mastering the Unpredictiable” in the section named “Building the Solution with ACM”: “Describe the business entities as the first step of setting up a solution with and ACM”. And later: “Describe the relations between the business entitites”.
I agree totally: it must be done. But not by business users.
Michael, Keith
Seems that you are on different positions about whether ACM relates to processes, am I right?
Bravo Anatoly for the excellent post.
Thanks,
AS
mentioned on SAPERIONblog as comment on “Gartner pushes Case Management in the context of PBM. Old wine in new skins or …?”
http://www.saperionblog.com/lang/de/gartner-pushes-case-management-in-the-context-of-pbm-old-wine-in-new-skins-or/3348/#comment-6211
This topic is followed at ebizQ forum: http://www.ebizq.net/blogs/ebizq_forum/2011/01/is-acm-a-new-paradigm-or-a-bpm-feature.php
Анатолий, спасибо, действительно хорошая статья. Часть комментариев уже высказана и я не будут их повторять. Но есть один момент, на который, похоже, мало кто обратил внимание. Это новые роли, возникающие в ходе исполнения и развития бизнес-процессов.
В ACM есть роль, отсутствующая в BPM, а именно case worker. Я соглашусь с тем, что большинство участников бизнес-процесса не должно быть их архитекторами. Иначе возникнет хаос. Но должен быть кто-то «умный», способный вмешаться в ходе исполнения экземпляра процесса… главный бухгалтер, мастер на производстве (SCRUM-мастер у программистов), наставник и т.д. Ваша статья затронула тему появления новой роли. Его можно назвать менеджером процесса, можно назвать аналитиком, можно – архитектором. Главное, что этот персонаж находится внутри процесса, а не где-то за сценой и влияет на процесс в ходе его исполнения.
Я считаю, что это самое интересное в происходящем. Кто эти люди, где их брать и как учить, каковы их полномочия, какие им нужны инструменты. Вопросы, вопросы…
Ну, не знаю… все-таки архитектор - это одно, а прораб - другое. Всегда есть кто-то на сцене и кто-то за сценой. С точки зрения BPM, архитектор нужен всегда, а прораб - только для некоторых процессов. Для строительства дома нужен, а для приема заказа на кирпич для этого дома вроде бы и нет.
Анализировать, обобщать, планировать у одних получается лучше, чем у других. Теперь представим себе две организации: в одной этих людей как-то выделяют и поручают им думать “за себя и за того парня” (насколько это возможно, конечно), а в другой постулируется, что все работники умственного труда равны, все сознательны и нельзя никому ничего навязывать (один из постулатов ACM). Какая организация победит в конкуренции? Я лично поставил бы на ACM-ориентированную только тогда, когда речь идет о молодых и/или небольших организациях. Обличать бюрократию так, как это делает Ваш тезка,- по-моему, это не по-взрослому.
Вообще же найти роль, которой нет в BPM, будет непросто. К примеру, BPM Common Body of Knowledge (BPM CBOK) описывает следующие типовые роли:
- Process Owner
- Process Manager
- Process Analyst
- Process Designer
- Process Architect
Там же сказано, что опрос организаций, практикующих BPM, дал свыше 100 должностей и ролей.
About roles — maybe a super-user? See http://improving-bpm-systems.blogspot.com/2010/05/who-is-doing-bpm.html
Thanks,
AS
Анатолий, подозреваю, что прораба (сокр. от производителя работ) в этом списке нет. Того самого Владимира Николаевича в исполнении актера Любшина из культового фильма Кин-дза-дза, способного ориентироваться в пустыне чужой планеты, современным компаниям и не хватает.
Александр, согласно вашей таблице super-user больше разбирается в системе, чем в технологии. Я же говорил в большей степени о технологе, прорабе, мастере, Конечно, если он еще и в информационную систему может своими руками залезть и данные без красивого графического интерфейса подредактировать, то цены ему нет.
Максим
Все правильно, в списке “процессных” ролей прораба и не должно быть. Старик Раммлер правильно учил: не пытайтесь выстраивать какой-то параллельный процессный менеджмент, отдельный от просто менеджмента. Это всего лишь аспект нормального менеджмента: если у вас отсутствует процессное мышление, то вы слабый менеджер. Просто слабый менеджер, а не слабый “процессный менеджер”. И процессный менеджер со стороны тут ничем не поможет - вот это, действительно, будет в чистом виде бюрократия.
И это не абстрактные рассуждения: у наших заказчиков роли собственников процессов и процессных менеджеров играют “нормальные” менеджеры верхнего и среднего звена, соответственно. Зачастую даже не догадываясь, что против их имен в титрах стоят такие мудреные роли
Кстати, еще один совет Раммлера: собственник (process owner) нужен далеко не всем процессам, а только кросс-функциональным процессам верхнего уровня. Тоже нельзя не согласиться.
Что касается нехватки прорабов: что, земля оскудела талантами? Не думаю. Словами того же Раммлера (что-то меня сегодня понесло цитировать): поставьте индивида против системы, и система победит в ста случаях из ста.
My observation — we may need to distinguish between process-template owner and process-instance owner. The latter may be a “прораб”, a user, a super-user or, even, a line manager.
Also, I noticed that some cross-functional top-level business processes may have a collective process-template owner, i.e. a committee. And no one wants to be an owner of instances of those processes.
@Maxim — a super-user has some rights to adapt a BPM tool to the needs of the business. Sure, he/she is in some extend “технолог”.
Thanks,
AS
Totally agree.
Another analogy: process owner is a judge, process manager is a police officer.
Or process owner = congressman? OK, it’s a poor analogy altogether.
Неожиданный поворот в дискуссии
Barely a Year Old, and ACM is Dead
http://www.bp-3.com/blogs/2011/02/barely-a-year-old-and-acm-is-dead/
ACM is Dead! Long live ADAPTIVE!
http://isismjpucher.wordpress.com/2011/02/14/acm-is-dead-long-live-adaptive/
Анатолий, что вы скажете вот на эту статью? http://itau.ru/2011/05/21/protsessyi-organizatsii-opisanie-formalizatsiya-reglamentatsiya-na-primere-printsipov-acm/
Очень интересно
maxxannik
Это Ваша статья?
Keith Swenson has authored a book on ACM caleld “Mastering the unpredictable”..and what s interesting is that it seems ACM is very similar to KM in that it talks about non-routine, unpredictable work what we call knowledge work. Another way of looking at it is when not to use BPM.
To be precise, this book was written by a number of authors.
Статья замечательная. Актуальности не теряет. Перечитал снова с удовольствием.
Анатолий, являясь признанным гуру BPM, делает в статье важный вывод, что ACM тоже имеет право на существование :).
Сейчас, по прошествии некоторого времени, я уже могу утверждать, что ACM и Social BPM это практически одно и то же.
Max the Papyrus Pusher будет категорически против. Keith, скорее всего, согласится.
Max утверждает, что ACM, в отличие от BPM, позволяет достичь цели. Цель в ACM - это все, а переговоры экипажа (social networking) значения не имеют. При этом он не может формализовать понятие цели, а может лишь на страницу описывать свои ощущения, когда он думает (мечтает?) об этом понятии. Поэтому реализация цели в его продукте ничем не отличается от реализации задачи.
При попытке формализовать понятие цели (в корпоративных процессах, не в системах наведения баллистических ракет) любой сразу поймет, что это понятие социальное и реализуется в информационной системе только с привлечением социальных сущностей - дискуссий, поручений (human tasks) etc.
Итак, на сегодня, ACM это Social BPM. Не расширение BPM, не подмножество, а смежная область. BPM автоматизирует predictable процессы. ACM автоматизирует unpredictable human activities этих же процессов. В целом автоматизация получается более полной - сотрудники, обслуживающие эти процессы, теперь реже будут вынуждены отодвигаться от компьютера, чтобы решить вопрос по телефону.
Спасибо за комментарий и за комплименты. Продолжаю размышлять над ролью и местом кейс-менеджмента - http://mainthing.ru/ru/item/681/
По поводу социальности, про которую “любой сразу поймет” - меня вычеркивайте, так что не любой по-любому
Что является целью организации? Вопрос очень дискуссионный. Я лично склоняюсь к тому, что организация - это форма жизни, а целью жизни является жизнь, т.е. возможно более длительное существование. Будет организация существовать - будет и все остальное, включая пресловутый возврат инвестиций.
Если же оставить философские дебри, то как социальность поможет решить проблему “корпоративного пинг-понга”? Никак. Только сделает его более технологичным: раньше департаменты футболили друг друга посредством служебок, затем перешли к более прогрессивому методу - с помощью мыла, а теперь для этого у нас будет внутрикорпоративный фейсбук. Неррешенным остается фундаментальный вопрос - кто,, кому, на каком основании будет раздавать задачи в рамках кросс-функциональной проблемы? Или само как-нибудь?
Что касается взаимоотношения ACM и BPM, то я верю в конвергенцию. Просто потому, что между кейсами и процессами нет непредолимой стены - они запросто мутируют друг в друга. Следовательно, инструмент должен быть един.
Анатолий,
>>любой сразу поймет” - меня вычеркивайте, так что не любой по-любому
Что является целью организации? Вопрос очень дискуссионный.
не буду вычеркивать, поскольку 1) согласен и 2) этой фразой подтвердили правоту моего высказывания, что цель (например, организации) - сущность социальная и без дискуссий (хотя бы владельца компании с самим собой) не определяется. Более того, усилю ваше высказывание - вопрос о цели в разных практических случаях может быть настолько дискуссионным, что в принципе не иметь ответа в виде точной формулировки цели. Отсюда уже можно сделать вывод, что системы, которые уверяют доверчивых пользователей, что умеют оперировать целями, как минимум, неполны, а утверждения системных архитекторов таких систем о наличии такой функциональности, как максимум, недостоверны.
>>как социальность поможет решить проблему “корпоративного пинг-понга”?
Очень хороший вопрос. Самый важный. Ответ на него существует. Оперировать не целями (которые часто и сформулировать нельзя, см.выше), а ответственностями. Лицо, Принимающее Решение (ЛПР, замечательный ведь термин когда-то был придуман, эх, вспоминаю с ностальгией кафедру Исследования Операций ВМК МГУ) на своем уровне компетенции принимает решение, какая активность подведомственных ему сотрудников соответствует цели, а какая нет (словесное определение таким ЛПР локальной цели и оценка действий сотрудников зависит от образования и воспитания, главное тут, что разделены сферы компетенции - люди занимаются своей непредсказуемой деятельностью и пытаются понять друг друга, а информационная система фиксирует эту деятельность и ПОНУЖДАЕТ ЛПР принимать решения, не пытаясь рулить непонятными ACM целями). И, соответственно, такое ЛПР отвечает за принятые решения перед другим ЛПР, которое действует точно так же. Вот и все. Вместо дерева целей строится дерево ответственностей, причем строится адаптивно, как часть кейсов в библиотеке шаблонов кейсов. За возникающий “корпоративный пинг-понг” всегда ответит соответствующее ЛПР (владелец процесса, в терминах BPM, но для ACM термин ЛПР лучше подходит, так как таких ЛПР с соответственными уровнями компетенции в одном кейсе может быть много). Нерешенный фундаментальный вопрос (кто, кому, на каком основании будет раздавать задачи) начнет с помощью такой ACM решаться - принятие решения по любой ерунде в реальной корпоративной жизни часто эскалируется на самый верх, а тут появляется инструмент для совершенствования этой процедуры - формирование библиотеки шаблонов кейсов, в которых начнут фиксироваться ЛПР по самым разным аспектам короративной жизни, от закупки скрепок, до приема на работу генерального директора. Термины ЛПР, ответственность - сущности социальные, и их привнесение в конструкцию ACM, собственно, и превратит ACM в социальную BPM.
По поводу ЛПР: наука не стоит на месте и изобрела термин ЛДПР: лицо, действительно принимающее решение
Намек понятен? Нет никаких гарантий, что десяток людей, назначенных ЛПР в рамках кейса, не будут заниматься имитацией бурной деятельности и спихотехникой. Это происходит без ACM, и я не вижу как ACM (понимаемый как технология) может с этим справиться.
Я вижу каких усилий стоит договориться по владельцу и по схеме процесса в BPM, какое сопротивление приходится преодолеть в каждом проекте, чтобы люди наконец поверили и поняли, что система - не враг, а помощник. Причем в BPM люди договариваются “на берегу”, а в кейс-менеджменте преполагается, что они смогут договориться кто что должен сделать “на бегу”, прямо по ходу раскручивания кейса. Не верю.
ACM в вашей трактовке не решает фундаментальную проблему функционального управления, заключающуюся в трении на стыках между функциями, а маскирует ее. В отличие от процессного и проектного подходов, которые прямо нацелены на ее решение.
Чтобы ACM был работоспособен, он должен позаимствовать методологию либо из процессного, либо из проектного подхода. Скорее из второго. Не ЛПР нужен кейсу, а менеджер проекта. Причем кокретного экземпляра кейса, а не всех кейсов данного типа.
Имитация бурной деятельности и спихотехника начнут уменьшаться (но на 100% не прекратятся никогда), как только сотрудники, назначенные ЛПР в кейсах, начнут реально отвечать за невыполнение работы в соответствии с деревом ответственностей.
Спихотехника возникает, если у кейса нет ЛПР, отвечающего перед другим ЛПР в соответствии со структурой дерева ответственности.
ЛПР не только принимает решения, оно еще и отвечает за свои решения. Если кейс завис или зациклился, а ЛПР эту проблему не разрешил, то ответственность за проблему эскалируется для решения вышестоящему ЛПР, в результате кейсы обязательно начинают совершенствоваться - либо ЛПР и другие сотрудники начинают работать, либо меняется ЛПР, либо совершенствуется структура кейса.
Собственно, так и реализуется адаптивность в ACM. Поэтому ACM позволяют автоматизировать бизнес-процессы предприятия «as is», в привычном для сотрудников виде, не подвергая риску процесс внедрения, не подвергая стрессу персонал, не ломая существующих бизнес-процессов для достижения теоретически правильного состояния «to be». Возможный «хаос», который поначалу при этом автоматизируется, становится качественно иным – измеряемым и контролируемым. После внедрения ACM бизнес-процессы становятся прозрачными, появляется возможность совершенствовать их на деле, а не на бумаге – меняя и улучшая шаблоны кейсов.
Чем ваша картинка с ответственностью ЛПР и эскалацией проблем отличается от стандартной структуры ответственности руководителей и эскалацией проблем в чисто функциональной организации? На мой взгляд, ничем. К чему это приводит в функциональной организации хорошо известно. На чем основана ваша вера в то, что в кейсе что-то будет по-другому мне лично не понятно, извините.
На мой взгляд, кардинально отличается, странно, что это не очевидно - тем, что реализованная в ACM структура ответственности будет работающей технологией, сигнализирующей об отклонениях немедленно, а структура ответственности, изложенная в бумажных корпоративных докуменентах (либо даже в некотором софте, не контролирующем текущую деятельность сотрудников), действительно неэффективна.
Сама по себе модель стандартной иерархической ответственности руководителей и эскалацией проблем в функциональной организации очень даже неплоха - проблема не в ней, а в ее реализации, в том, что она часто не работает, так как нет контролирующей эту ответственность технологии, привязанной к ежедневной деятельности сотрудников.
Привязка каждодневных кейсов сотрудников к структуре ответственности и немедленная эскалация проблем по принадлежности - это и есть то преимущество ACM, которое еще надо реализовать, конечно. Но на концепцию ACM такая модель стимулирования исполнения процессов организации в направлении к корпоративным целям ложится очень хорошо. Таким образом решается фундаментальный для ACM вопрос о способах достижения цели с помощью ACM - до сих пор ясного изложения того, как это надо делать в ACM, никто не предложил. Достаточно посмотреть дискуссию, предложенную Свенсоном “Do tasks, goals, and activities have to be handled differently in a plan?”, чтобы увидеть какие творятся разброд и шатание даже по базовым терминам ACM. Это очевидный нонсенс, так как ACM по определению являются goal oriented systems, а что же такое goal, никто не знает - на формальном, программируемом уровне, конечно, на вербальном мы все горазды - в блоге писать не мешки ворочать.
Более того, берусь утвержать, что без такой привязки к структуре ответственности любая автоматизация коллективных процессов будет неэффективной. Если кто-то сможет рассказать о способах коллективно двигаться к цели без контроля ответственности, то я сильно удивлюсь
ОК, раз не получается согласиться, давайте согласимся, что мы не согласны
Спасибо за интересное обсуждение!
Также большое спасибо. Для меня согласие собеседника желательно, но не обязательно, достаточно отсутствия очевидных аргументов против
Anatoly great article! For 10 years I’m working on the concept of dynamic BPM, which seems to be predicted by you “new BPM”. In fact, dynamic BPM is an extension of traditional, static BPM. Take a look at: http://www.bpminstitute.org/resources/articles/does-modern-technology-impede-modern-management
or http://jemi.edu.pl/uploadedFiles/file/all-issues/vol10/issue1/JEMI_Vol10_Issue1_2014_Article_6.pdf
And a great asking for your comments. Best wishes. marek