Freddie van Rijswijk recently pointed me to Andrea Westerinen’s blog and her article on Role Activity Diagrams for business process. It mirrors my personal perspective on what is wrong with common business flowcharting such as with BPML. BPML is no more than a programming language and is not suited for collaborative processes. Because of the necessary human initiative, judgment and intuition 80% of all business activities are collaborative in nature. Westerinen – like me – says business users continuously adapt a process and how they perform it and therefore a BPM solution should be supportive and not restrict the business user.
The article references a 1983 paper by Holt, Ramsey and Grimes in Electrical Communication and a 2005 book by Keith Harrison-Broninski in which Role Activity Diagrams (RAD) are used to describe processes in a more human way. RADs cover role responsibilities and interactions, resources, activities, and the process states. If we consider that resources are some business data and mostly content then RADs match the ISIS Papyrus process concepts perfectly. I admit that RADs are new to me, but it is intriguing to see that in 1983 someone already looked at process the right way, which means from a human perspective. You know from my previous blogging that I even think that Michael Hammer never proposed BPM the way it is sold today. I propose that the whole SOA, BPM construct spends a huge amount of money and valuable time to create a business straightjacket.
SO, am I proposing to use RAD diagrams to define business processes? Absoutely not. I am just pointing out that I am not alone in my thinking. I might look at adding RADs to the portfolio of UML-like diagrams in Papyrus WebRepository but their main use should be documentation and tuning but not process creation. So how should processes be created? I truly believe, not at all. Processes have to be discovered and adapted more or less automatically. As it happens, the Papyrus User Trained Agent (UTA) has succeeded in that part, but we are still struggling to get it accepted because we have to somehow make its knowledge understood. People seem to trust that other people know what they do after they were trained, but not in a software product. They want to open the computer brains and inspect them. So we are adding knowledge visualization to the UTA to enable that. I feel it is unnecessary and creates again more complexity.
You also judge a cook by how his food tastes and not if he uses the right procedure.
I am the founder and Chief Technology Officer of Papyrus Software, a medium size software company offering solutions in communications and process management around the globe. I am also the owner and CEO of MJP Racing, a motorsports company focused on Rallycross or RX, a form of circuit racing on mixed surfaces that has been around for 40 years. I hold 8 national and international championship titles in RX. My team participates in the World Championship along Petter Solberg, Sebastian Loeb and Ken Block.
Welcome to the Real World! 
Max – intrigued by your observations such as… “I challenge the suitability of flowcharts… Knowledge based processes can’t even be represented by flowcharts at all…”
Given that, you just might be interested in our project, in the cloud at http://www.kgenes.com – any comments (+ve or otherwise) thoughtfully welcomed.
LikeLike