Resolved
5 votes

Suggested by Peter Hilton: Why do you think business process model repositories never quite succeed?

Thursday, January 14 2016, 09:47 AM
Share this post:
Responses (20)
  • Accepted Answer

    Thursday, January 14 2016, 09:56 AM - #Permalink
    Resolved
    7 votes

    Because we need processes, not models?

    Like
    1
    • Patrick Lujan
      more than a month ago
      Models are an agreed-upon representation, implementation of process(es) for an agreed-upon purpose, objective. They're not as bad as you think and can provide tremendous lift if done well and incorporated correctly into the overall big picture, solution, implementation.
    • Emiel Kelly
      more than a month ago
      I'm not saying they are bad. But in the end it's about the processes. Still see too often goals and means mixed up.

      As you said; with a purpose I like every means.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, January 14 2016, 10:00 AM - #Permalink
    Resolved
    7 votes

    In accordance with the 5th law of BPM (see ref1) , "The vast majority of unique business processes can be constructed from a limited set of business-centric patterns." thus we need a repository (a catalogue, animation, examples, etc.) of practical process patterns (see ref2).

    Thanks,
    AS

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, January 14 2016, 10:03 AM - #Permalink
    Resolved
    6 votes

    Because they are not:

    1/ granular - people who build these repositories believe a best-in-class S2P cycle is the same for everyone

    2/ specific - vertical domains should be used as accelerators, instead of the current horizontal approach

    Micro-process-as-a-pattern should be the way to go, but this requires an uncanny ability to abstract the whole business model of an enterprise and then go back and translate every piece of it into a friendly domain-specific language for the regular laymen. Not sure it's entirely possible but some focused nutcase could make some progress here.

    In fewer words: a "PCF" approach is great for consultants, not for their implementing customers.

    Like
    1
    • Patrick Lujan
      more than a month ago
      Yyyep.
    • Peter Hilton
      more than a month ago
      ‘PCF’?
    • Bogdan Nafornita
      more than a month ago
      PCF = Process Classification Framework
    • John Morris
      more than a month ago
      "PCF", either APQC's Process Classification Framework or a political party in France. I think the former.

      As for micro-process-a-pattern being the way to go, agreed. I think this can be seen as a way of addressing the whole "tacit" work problem, i.e. that reality is so rich that useful modeling is either too expensive or impossible. Or something. Instead, try little Lego(R) building blocks. I volunteer, but won't admit to anything. : )
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, January 14 2016, 10:03 AM - #Permalink
    Resolved
    5 votes

    I'm sure many of my current, and past, colleagues will argue that they rarely see this happen. I like the term model, or map, because it helps actors within a process understand that what they are looking at is an abstraction not the reality of the process. It's important, in some cases but not all, that these actors have a simple and clean way to talk about how stuff works today so they can improve it tomorrow.

    In areas where we see a lot of change, having a common reference model that everyone understands is very useful to help the team undertand and overcome unexpected changes. This is where I see these repositories being used today.

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, January 14 2016, 10:30 AM - #Permalink
    Resolved
    7 votes

    Multiple reasons, slight variances on Dr. S's and Bogdan's weigh-ins above:

    1. Intellectual property
    2. Axiom: "A process model does not a performant workflow make." Models' implementation varies from one process engine to the next, they're respective idiosyncracies, "tips, tricks and traps."
    3. Effort. Bogdan's comments about abstracting the whole business model or enterprise and then going back and translating is spot on because it's 1) too hard, 2) too time consuming, 3) too expensive for most orgs' palates. Most orgs are real good at day 1, not so much at day 2. Takes tenacity and perserverance. That's read in italics as "political will" and "money."

    That being said I like Dr. S' "practical" patterns a lot and have used them at my most recent client. The "uncanny ability" part comes with reps, more "weight on the bar."

    Just my tuppence.

    • Peter Hilton
      more than a month ago
      To me, these all sound like arguments why Wikipedia cannot possibly exist. In particular, a Wikipedia article does a knowledgable person make, but it’s still very useful.
    • Patrick Lujan
      more than a month ago
      Tell me how often you ready something on Wikipedia that's immediately, tangibly actionable without modification, extrapolation, customization, not just talking the talk after a few minutes reading.
    • Peter Hilton
      more than a month ago
      Ah, I now see what I didn’t explain properly. I believe that a useful process repository would have examples that are a more useful starting point than a blank page, which would then require substantial effort to understand, adapt and apply. I’m not suggesting that a published model could be ready-to-use, just that studying a number of variations of a model would be a good starting point for making your own.
    • Patrick Lujan
      more than a month ago
      I like the idea, the concept, just don't know how much traction it would get given my own criteria listed. That being said, I've been following, studying patterns since day 1 with van der Aalst and if it could be taken to the next level with models, you bet. :-)
    • Peter Hilton
      more than a month ago
      Here’s my take on taking van de Aalst’s patterns to the next level: http://www.effektif.com/news/workflow-modelling-patterns/
    • Bogdan Nafornita
      more than a month ago
      I have also been following the "patterned BPM" literature and frankly it varies from totally useless (like a task chained to a simple XOR gateway) to really good specific clues (especially around error treatment, which is huge by itself), going through the famous Enterprise Integration Patterns.

      But really, there is still no EIP v2.0, really focused on business patterns, rather than ESB-like patterns.

      So much to do, so little time - but I have an idea... :-)
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, January 14 2016, 10:34 AM - #Permalink
    Resolved
    6 votes

    Well... Ok, here it goes:

    It's absolutley not about storing process models (that already happens many times for better or for worse...), but it is about having a single source of (governed) hierarchical truth in an easy enough to understand presentation for the business. There, I said it.

    Any process related information (roles, people, tools, technical detailed blueprints, procedures, KPI's, compliance references, cookies and coffee, ashtrays etc.) should, in principle, be represented in the context of this truth. And if an artefact doesn't fit, what exactly does it contribute to your business in the first place?! So far the theory...

    9 out of 10 customers I visit, can tell me (basically) WHAT they produce, However: HOW they do it, (let allone WHY they do it), remains many times one big foggy swamp. It's an enormous waste that process (related) information needs to be constantly created or looked after from scratch, project after project. I do understand that you cannot have a one-2-one blue print of every single activity in your company, but at least you should have a level 1-3 representation acting as the umbrella context and extend where most needed. Not as isolated documents in a Sharepoint site.

    Obviously technologies such as process mining could create realistic AS-IS of your business. But these need, guess what, also be in context of the whole.

    And when you do not get the above, well, that's  why it won't take off IMO. :-)

    • Patrick Lujan
      more than a month ago
      That's process maturity. Not only what we do, but why we do it that way and what that gets, buys us based upon our own org's goals, objectives.

      That being said, yeah, few do it, fewer still do it well.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, January 14 2016, 11:03 AM - #Permalink
    Resolved
    4 votes

    Great article by @PeterHilton.

    He suggests the need for a repository with the following characteristics in order to make repositories successful

    1) Public Online Content

    2) Public Editing

    3) Modeling Discussion

    4) Model Variation

    5) Open Licensing

    6) Multiple Languages

    I couldn't agree with this more with one major caveat. There are two main models for "Public" Editing, viz. the Wikipedia model and the Github model. (For those not familiar with Github it is THE open source software repository on the Internet).

    In the Wikipedia model, literally anyone can directly edit the page. In the Github model, there is a notion of a "pull request". i.e a person other than the owning team can clone the code, make changes and issue a "pull request". i.e. request the owner to merge their changes in. For semantically interrelated artifacts like code (or processes) a direct edit public edit model is not really viable.

    So, a pull request model requires

    a) Allow anyone to clone public processes

    b) Make changes to the cloned process

    c) Issue a pull request

    d) Owner can merge it in creating a new version of the public process.

    Similarly, a forking model (also supported by Github) where the code is forked and never pull-requested is also critical to the innovation seen in Open Source software.

    One additional point I would like to make relative to the referenced article:

    Peter Hilton Wrote:

    "Currently, process model repositories generally don’t allow public access, and are written by a single source, instead of allowing public contributions. This is how encyclopaedias used to be produced, before they inevitably gave way to Wikipedia."

    At TMail21 we do support public repositories (and the characteristics 1-6 above) with a couple of caveats

    a) For #1, the processes are public (we also support organization-private processes) but are behind a free registration 'wall'.

    We plan to remove the registration wall for public processes shortly so they can be directly indexed by Google.

    b) For #3, the modeling discussion is not currently public but specific to the "owning" organization. But this is a great enhancement to consider.

    and the following related points

    i) For #2 We use a github style pull-request type model for public editing rather than a Wikipedia style direct-edit model. (which I believe is the appropriate approach)

    ii) We also support the github-style forking model in addition to the pull-request model.

     

    Like
    1
    • Peter Hilton
      more than a month ago
      When I wrote ‘public’ I definitely meant on a publicly accessible web page, so I call something that requires registration ‘private’, regardless of whether the registration costs money. I’m certainly intrigued about the value you’ll get from removing the registration wall and the correspondingly bigger audience, like public GitHub projects have.
    • Ranjit Notani
      more than a month ago
      @PeterHilton, yes, it will certainly be interesting to see how making it "fully" public plays out. All public processes will be indexed by Google et al which should be interesting. Of course when Google indexes these they will lose any semantics (such as field types, process states etc). Need to research whether Google indexes the Github code itself (equivalent to process semantics) or just the textual descriptions of the code.

      And of course every Process (and Process version) will get its own public URL (currently they have internal (public) identifiers like My_Awesome_Process/acme.com).

      Once again, great thought leadership!
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, January 14 2016, 11:32 AM - #Permalink
    Resolved
    5 votes

    It's a very good question...

    We have modelled and optimised the same business processes for different clients in the same industries such as Automotive, Consumer Goods, Financial Services, Government, etc. etc. At the AS-IS stage we typically find almost identical processes, with the only differences being cosmetic or down to local terminology or cultural tradition. Occasionally we find a 'smart' process that is saving sufficient time, money and waste to create a competitive advantage. Quite often the client is oblivious to this and, before we embark on TO-BE, we have to spell out to the Exec team the potential they already have.

    In the commercial sector, process differentiation should rightly be seen as one of the key means of competitive advantage, but should that view also apply in the public sector? Isn't there a clear need to identify and share best practice for all citizen services in order to ensure consistency and optimise value for money?

    In UK Local Government there are 470 organisations each separately providing tens if not hundreds of citizen services which are almost identical. From collecting local taxes, handling waste collection, issuing building permits, the list is endless, but so are the local variations that we have found. From time to time we offer up the library of local government processes that we have built up over the years, but it generates little interest.

    Contrast that with Switzerland. A country I worked in for a number of years and with a total population about the same as London; but with 26 Cantons and 2400 Municipal Authorities. For some years, the Swiss Federal Government has been actively promoting the identification, modelling and sharing of business processes and advocating the adoption of 'best practice' throughout local administrative centres of all types. The advantages are seen as considerable: with some Municipalities serving only 1000 citizens, affordability means there can only be 2 or 3 local administrators.

    In other countries this might be seen as all the justification necessary for merging, eliminating and/or outsourcing local councils but the Swiss nation is fiercely proud of its local democracies and strives to find a better way through the sharing of its business processes.

    Like
    1
    • Peter Hilton
      more than a month ago
      The local government processes example is intriguing, because that could potentially provide a way to bootstrap a platform for publishing public domain processes. If that worked, then extending the repository with all kinds of other processes might be feasible, and perhaps even justified as part of a mandate to help businesses succeed. In the UK, I’ve been impressed by the vision and modern thinking of the GDS (https://www.gov.uk/government/organisations/government-digital-service) people I’ve met, especially with respect to giving local government alternatives to doing things the hard way.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, January 14 2016, 11:36 AM - #Permalink
    Resolved
    4 votes

    I started thinking about this question because it occurred to me that all of the likely objections to the feasibility of the idea are things that Wikipedia figured out how to solve. That’s why my blog post about The process model repository of the future is essentially an outline of What would Wikipedia do?

    I suspect that the difficulty of getting started with process modelling is a barrier to more widespread BPM adoption. While developing Effektif we can make a lot of the software support easier to use by simplifying the traditional approach to aBPMS, but we still present beginners with a blank BPMN diagram. We can provide some process examples, so people don’t have to start from a blank page, but we’re never going to be able to provide examples for everything.

    We have customers who are new to BPM and using Effektif to help coordinate a process that was previously based on Excel and email. They would benefit from a process repository that has multiple examples of similar processes to their own, ideally in the same industry, that they could use for inspiration. These process models are obviously not going to be usable as-is. Our business users would still have to understand their the example processes, understand how they relate to work in their own company, and adapt them to their own needs to make them usable. These hard parts of process modelling don’t go away. But people wouldn't have to start from scratch.

    • John Morris
      more than a month ago
      Peter, your championing of process patterns is great -- especially if it can get us beyond "the blank page". Which is a terrifying place to start.

      Here's an example a useful pattern: an escalation pattern for a field service instance.

      Escalation is a simple and common pattern that every vendor should have on the shelf to demonstrate. And yet we build escalation pattern examples, in response to customer request, from scratch. And if the sales engineer isn't DMN-friendly (i.e. we are able to abstract out the escalation rules to a simple, easy-to-understand-and-edit-escalation-rules-table), then the pattern looks like spaghetti -- and doesn't make a good impression on the business people in the room.

      So, my other comments notwithstanding, domain-specific patterns can and should become part of any IT or business leader's repertoire, along with debits and credits and cashflow and contract law etc.
    • Patrick Lujan
      more than a month ago
      .@JohnHMorris, check out @samarin's SLA pattern. Coupled with a good rules engine it's copasetic. ;)
    The reply is currently minimized Show
  • Accepted Answer

    Tim Bryce
    Tim Bryce
    Offline
    Thursday, January 14 2016, 12:09 PM - #Permalink
    Resolved
    3 votes

    Maybe people have an incomplete interpretation of what a repository is. I refer to it as "The View of the Company from 50,000 Feet," and, as such, should include much more than just processes. It should include business components (functions, jobs, people, machines, objectives, projects, and requirements), system components (systems, sub-systems (business processes), procedures, steps/tasks, programs, modules), and data components (data elements, records, files, inputs, outputs). All, of course, are cross-referenced. As such, it is the focal point for all development activities, not just BPM. The Repository here is used as a Bill of Material Processor which is invaluable for playing "what if" in changing a component (measuring the impact of change).

    I have written about this in the past. Below are two articles. Hope this helps.

    All the Best,

    Tim Bryce

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, January 14 2016, 12:23 PM - #Permalink
    Resolved
    3 votes

    Is a modeling repository like an an accounting chart of accounts? There is some similarity. But we won't worry about whether the idea of "charts of accounts are going to take off". They "just are".

    And part of "just being" is that process model repositories (even worse than charts of accounts) are many steps from value creation: (1) fund model curation in repository, likely a very fraught process; (2) fund model selection from repository for use; (3) fund model customization for specific requirements; (4) fund model deployment into production; (5) trigger create process instance in model; (6) and finally use process instance to support the work of value creation.This all-overhead value chain is hard to sell!

    And we haven't even explored whether a model is executable, or only supports analysis. Or how one keeps a deployed model in sync with central models.

    So rather than the implied Soviet-style repository business model, a more entreprenuerial model built around edge-oriented micro-processes-as-pattern (per @Bogdan) has promise in multiple dimensions: technically, financially and socially.

    • Bogdan Nafornita
      more than a month ago
      Fully agree with you John.

      With the risk of getting too philosophical, I do believe that business process management, being more about orchestrating human behaviour (among others), is more of an art than a science. In other words, there is no global optima that can be easily reached for any process.

      Accounting is far more of a science than an art, yet even there I see a lot of struggling to come up with universally accepted accounting principles (see the huge, multi-decade, effort to mitigate US GAAP to IFRS), universal set of presentation principles and of course a common reporting language (a la XBRL).

      So, if accounting is not there yet, how could BPM be?
    • Patrick Lujan
      more than a month ago
      @Bogdan, it ain't there. ;)
    • Ranjit Notani
      more than a month ago
      Great points @John,
      A couple of thoughts. With respect to funding (your point #1) one would have to ask who would benefit from creating public processes. I see the following
      1) Consultants (and consulting organizations) who do it to establish credibility.
      2) Company consortia and standards bodies especially for B2B processes
      3) Companies who are trying to establish a de-facto standard which benefits their business. Think the US Postal Service service establishing a standard process for online certified mail or Uber establishing a car booking process.


      Of course it would be helpful if the cost of creation of a process is low in the first place.

      The cost of selection, customization and deployment would need to be borne by the USING organization as they are the ones benefiting in that case.

      I don't view either of these as show-stoppers. Obviously all parties will have to do a cost-benefit analysis on a case-by-case basis.

      With regards to executability, in my opinion the the repository processes must be executable (like Github projects) otherwise the repository will become a glorified document repository.

      Here, having a "code-later" concept built into the process facilitates immediate execution with later (integration) optional coding.
    • Peter Hilton
      more than a month ago
      A chart of account sounds like something that lives inside a company. While I suppose you could try having a company-internal process repository, it wouldn’t be nearly as interesting as a public repository with contributions from everywhere.
    • John Morris
      more than a month ago
      @Ranjit -- good analysis on how shared process models might be supported in the marketplace. As for "code later", I associate a lack of executability with problems selling BPM. Either what-you-draw-is-what-you-execute, or you have just bought a more expensive version of Visio and the programmers are in charge, as usual.
    • John Morris
      more than a month ago
      @Peter, charts of accounts, admittedly not very complex compared to many processes, are more than just "inside". Here are examples of broad-ranging discussions on the topic illustrating the idea.

      Chart of accounts unable to support new cloud business models
      http://home.kpmg.com/uk/en/home/insights/2015/05/cloud-implications-for-finance-function.html

      Standard charts of accounts
      http://strategiccfo.com/wikicfo/standard-chart-of-accounts/

      Problems in chart of accounts design
      http://strategiccfo.com/wikicfo/problems-in-chart-of-accounts-design/

      Maybe in the future we will see similar discussions concerning standard process models?
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, January 14 2016, 01:17 PM - #Permalink
    Resolved
    4 votes

    When I collected my "practical process patetrns" I kept in mind the famous "Design patterns:Elements of Reusable Object-Oriented Software" book from the Gang of Four (see ref1) and, of course, cooking recipes. Their usage is simple:

    1. follow it as-is to understand it, and

    2. adapt it (step-by-step) for your needs/taste.

    Easy, it works and even worked in the Soviet Union. Of course, process patterns must be treated as a "public good" in the BPM community.

    Thanks,
    AS

     

    • John Morris
      more than a month ago
      Dr. Alexander, interesting reference to "cooking recipes", because of the question of the tacit. My wife and brother-in-law have both written cookbooks, and I've enjoyed learning about the "idea of the recipe". For example a recipe might say you should "fold in" some ingredient . . . which assumes one knows how to "fold in" . . . there's so much tacit knowledge assumed by the most cookbooks.
    • Dr Alexander Samarin
      more than a month ago
      Yes John, recipes use a lot of tacit knowledge about cooking. The vast majority of this tacit knowledge is a set of basic techniques whcih can be found in books about "good cooking practices". But cooking instructions like "Stir fry until ready" are difficult to make explicit.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, January 14 2016, 01:46 PM - #Permalink
    Resolved
    4 votes

    Judging from this thread, I'd say at least one reason is that people do not necessarily share the same idea of what a "process model repository" is. Wikipedia is the opposite: it is reasonably well structured, and there is widespread agreement about what constitutes an "article" (notwithstanding the fact that there are periodic discussions whether two articles should be merged, or one split).

    Those of us on the technology side assume that we should be able to create reusable libraries that can be picked up and plugged in where needed. But BPM doesn't actually work like that. Code libraries have extremely well defined inputs and outputs, and are specifically designed to avoid causing side effects (that is, changes to state or other information that is not contained within the library itself). They work best when they are simply dropped into place and used through a well defined interface.

    BPM configurations rarely work that way. You could keep a snippet in your repository for "legal review", for example, but the odds are poor that you'll be able to just drop that into your process without modification or side effects.

    Not coincidentally, the value of reuse is also much higher in coding than in BPM. Having to re-implement your sort function each and every time you need one is costly. Because you don't modify reusable libraries, it's always going to be cheaper to just drop in an existing one. But BPM snippets, as noted, very frequently need to be adapted to their particular use case. Although there are certainly exceptions, as an implementer, I have generally found it to be faster and easier to build new processes from scratch.

    • Dr Alexander Samarin
      more than a month ago
      RE “Code libraries have extremely well defined inputs and outputs, and are specifically designed to avoid causing side effects (that is, changes to state or other information that is not contained within the library itself).” – It seems you are talking about functional libraries which are typical for many programming languages. Process patterns mentioned above are design patterns. A software design pattern may be written as a fragment of C code and I have to recode it in my Python or Java code.

      Advantage of process patterns is that they help for different people find similar “solutions” in similar business situations. Thus better quality and less maintenance even for building new process from scratch.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, January 14 2016, 01:49 PM - #Permalink
    Resolved
    5 votes

    The seductive nature of BPM Software is that a business can model its own proprietary business processes so that the software fits the business instead of having to change the business to fit the software. This has long been one of the sexiest aspects of BPM, and it is certainly something that BPM Sales people exploit to maximum advantage. This is one of the main reasons why templates, process, and form libraries end up having so little value. Although they seem like a great idea to newbies to BPM companies (every new person we have hired into a senior sales or marketing management role comes up with that as their first brilliant idea), it really doesn't have much of an impact.

    Besides the workflows themselves differring, the other thorny aspect of the template library is a) the connectors to third party systems, and b) the way those connectors actually get used. This is where the possible combinations of the way the same process might look for different business starts to exand quite exponentially. It is one thing to connect to SalesForce to pull the name of a lead. It is quite another thing to pull this data in concert with product data from an AS400 and then feed a copy of an uploaded document to a very old version of Filenet.

    You see, BPM is, as we all know, all about connecting systems and people. So, although a purchase process sounds like it should be the same for everyone, it becomes quite different once you add in different ERP, CMS, ECM, and a few legacy systems. Oh, and then you sprinkle on top of all that the fact that every company will be using a slightly different version of each of these systems in a slightly different network configuration, etc. The result is that the simple purchase request process starts looking quite different for each business when modeled and automated in BPM Software. Yeah, I know, REST is supposed to offer a universally accepted contract between parties. It will happen....just hasn't yet.

    • Dr Alexander Samarin
      more than a month ago
      Hmmm, the cooking recipes which I saw didn’t specify how to turn on my oven or when to find some salt in my home. Process patterns mentioned above are design patterns. They may be defined in pseudo-BPMN thus to be adjusted to your in-house BPM-suite tool. (As we know, there is no universally executable BPMN yet)
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, January 14 2016, 07:58 PM - #Permalink
    Resolved
    2 votes
    One more thought: Wikipedia has the occasional article that describes a business process, e.g.

    So perhaps the best tactic for publishing a process repository that succeds in the same way as Wikipedia is to do it inside Wikipedia, following Wikipedia’s rules. Now where’s that List of business processses page…?

    The reply is currently minimized Show
  • Accepted Answer

    Ian Gotts
    Ian Gotts
    Offline
    Thursday, January 14 2016, 08:10 PM - #Permalink
    Resolved
    4 votes

    It is worth pausing to think about why Wkipedia works as "user-curated/managed content store"

    - there is a infastructure which users don't need to worrry about getting access

    - there is a setpredefined structure for the information

    - there is already stuff in there so you can see what you are aim for

    And most critically people actually care about what is in their "area" and are able to make/suggest changes and get them implemented very very quickly.

    Wiki's strenths are (taken fromhttps://en.wikipedia.org/wiki/Wikipedia:About

    • Wikipedia isopen to a large contributor base,
    • Allowinganyone to edit
    • Wikipedia iswritten by open and transparent consensus
    • Wikipedia iswritten largely by amateurs

    Build a process repository along these lines and it can and does work.

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, January 14 2016, 10:53 PM - #Permalink
    Resolved
    3 votes

    I propose that the problem is related to an ambiguity as to what the benefit is supposed to be.

    We have a repository in place at each customer but it contains a lot more than processes. Without reusable processes and templates we would never ever complete a project in time. Corporate users could never maintain their processes without a repository, and business people would not be able to work with the rerpository without simple reusable patterns and rules. But one cant just take that public. Wikipedia is a full text repository and Github is a source code repository. One is description, the other implementation. They could not be farther apart. Herein lies the problem. Typical Process repositories are neither nor because flow diagrams are at best just 20% of a usable process. The integration problems have been pointed out as have the lack of when, what, who, how and why descriptions in businesses. Another isuue is that hardly anyone in a large organisation actually wants transparency. At best they want numbers which if they actually get them mean very little due to a lack of common descriptors. Why? Businesses are social constructs and defy standardization regardless of how often BPM experts proclaim its benefits. Yes, some process decriptions are useful but they don't really enable automation. When Automation is enforced it kills people knowledge which over time kills the business. A business is not a factory floor. Hence a global BPM pattern repository does little to nothing in solving actual business problems. They might solve some implementation problems but like programmers process designers prefer to start from scratch than meddle with someone elses source code.

    To overcome some of these issues we have implemented a few years back an ontology layer in our repository. To describe the WHY in a more usable way than free text needs a term definition first. Its first use was to enable the writing of rules in business language already including the data variables. It was expanded to enable user interaction and we are currently working to enable the business to describe AND interact with an application. It needs to support multiple languages and synonyms as well.

    We imported for example the ACORD insurance model which is a kind of public repository only to find that it is 80% technical and cant be understood by business. That is the main use of an ontology in our book. We need to import hhe decriptive texts as well and not just the definitions. We then needed to provide a business filter to remove all the technical stuff from view. The ACORD model contains no processes and nothing in terms of WHY either. But now business people can use the ontology to describe the WHY and HOW in goal-oriented processes. Is that now reusable? Yes, theoretically. But as businesses are unique they want to use their own terminology and their own processes. But at least we have brought it all closer to the business. Do they now benefit from a public repository? No.

    • Dr Alexander Samarin
      more than a month ago
      RE “Hence a global BPM pattern repository does little to nothing in solving actual business problems.” It does by allowing staff members to concentrate on the unique challenges of their business and not waste time re-inventing the wheel.

      Good Business Practices (GxP) are useful although all businesses are different. Public cooking recipes are useful although cooked meals are different. Software design patterns are useful although all software products are different. Standard techniques in chess are useful although all chess games are different.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, January 15 2016, 09:52 AM - #Permalink
    Resolved
    3 votes

    I think a comparison to a Wikipedia digital asset model is far-fetched. On top of the reasons outlined above by various commenters, I would add:

    1/ role of the crowd

    the main value proposition of crowdsourcing is "in large enough numbers, the crowd is right, even given a minuscule marginal value of the individual contributions".

    I have a hard time picturing the BPM people as a large enough crowd, for the purpose of contributing meaningful, valuable and universally accepted process models.

    2/ asset criticality

    Wikipedia provides hyperlinked definitions and references. These assets have marginal value as information. Hence they are not mission-critical.

    On the other hand, executable public process models, if affected by amateur contributors and (highly likely) unscrutinized and untested, can derail an entire business.

    3/ asset dimension

    Linked to 2/ above, it is far more demanding to review and ammend towards a global optima a complex, heavy asset such as a process model. We can't compare this to grammar corrections or removal of broken hyperlinks.

    • Dr Alexander Samarin
      more than a month ago
      Sure, models in a process repository must by maintained by the BPM community not by the crowd. At the same time, the repository may be crowdsourced with ideas, comments, discussion, etc. Imagine a quality system documentation in an enterprise - everyone can read, comment, etc, and only designated people can modified. Thus jumping to Wikipedia was a bit confusing. Usually, I say - let us keep those digital assets in "à la wikipedia" manner.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, January 15 2016, 12:32 PM - #Permalink
    Resolved
    1 votes
    Our 20+ years of R&D and some £10m established that there are less than 13 process tasks (including the UI) that combined with flexible links facilitating collaboration (the step beyond workflow) and required rules, that address all business process requirements. After our early work proving the validity we created the ability to all be represented in graphical format “the model” allowing business people not IT to configure their business process requirements no coding required (other than if complex algorithms/ calculations) and no code generation. Just a simple click and declared through to the database which stets up automatically as required and ready to run. Even we have been surprised at the capability to build highly complex processes.
     
    This is “our repository” yes only 13 generically expressed components that really do build any process requirement. Of course needs to recognise legacy so in built tag library from UIs and SSMQ from the tasks so facilitates all – just need old IT to open up legacy!
     
    So why have we struggled be “take off”…? Fact is we were decades ahead of our time in an industry that has prospered on complexity in business software and now dominated by a few large companies. So many vested interests as this Model Driven Engineering is highly disruptive it brings to reality what is called the innovator’s dilemma’ basically why would the current supply chain cut their own throat! The speed of build and change is a paradigm shift with first cut in hours not weeks This will open the door to a new model of selling business software as it becomes a commoditise product where lease buy will replace SaaS and processes are assets owned by the buyer – no lock in!
     
    But it looks like change is coming as so many saying to bring that digital and people focus into software do not even think of changing legacy…use it do not change it. Also the growing recognition of the power of a “model” exampled on LinkedIn one such forum Model Driven Architecture (if you want a better description of what we created see on this site How Declarative MDE Allows the Model builder to create Enterprise Adaptive Applications Even the fact this question appears on this forum and as I write 18 responses is very encouraging! Be sure it will happen but needs some innovative plans to go global ….nearly there…..
    • John Morris
      more than a month ago
      Quote: "This will open the door to a new model of selling business software as it becomes a commoditised product where lease buy will replace SaaS and processes are assets owned by the buyer – no lock in."

      Radical! And I like the fact that the word "sell" is central.

      Now the new challenge is to build a business around a commodity -- per your reference to "commoditised products".

      Again, back to accounting. Basic accounting, a.k.a. bookkeeping, is performed by in-house (or even outsourced) staff. But bookkeepers don't make accounting policy changes. When you want to make an accounting policy change, you call in your boutique accounting specialist, a.k.a. "your accountant".

      Your accountant has a long-term relationships with you. They know your business. They don't shop your secrets down the street.

      Substitute "BPM" (which we can add other business semantic software specialties such as rules and statistics) for accounting. Voila, the boutique BPM shop of the future.

      And the BPM product vendor sells to the boutiques. And there's open source too. But boutique part services are not a commodities.

      It's how the accounting business works now. It's how BPM will work in the future -- when you deliver the software that makes it possible to deliver value "in hours, not weeks".

      My question is whether or not accounting firms will just vacuum up BPM expertise. I suspect the span of expertise will be too wide.
    • David Chassels
      more than a month ago
      Hi John
      You are spot on with the question "My question is whether or not accounting firms will just vacuum up BPM expertise. I suspect the span of expertise will be too wide." Someone at "C" level must take responsibility for the vital "Assurance" that organizations have mechanisms to ensure all data is accurately created, tracked and reported.

      Frankly Accountants have failed in recent past as "IT" failed to deliver yet they have that responsibility to give that "assurance" in the published accounts. As next generation BPM supporting software comes a reality as now being described that door opens up but will the Accounting profession rise to the challenge? Well I think they will after all back in the 70s they were walking round places of work talking to people and mapping our processes looking for weaknesses where audit could focus....then IT came along....so it is back to basics of how business really works! 2016 will likely be the time to see who rises to this challenge?
    • John Morris
      more than a month ago
      David, you've shared a compelling history of accounting-meets-IT. And that history as shared is focused mostly around assurance and risk -- i.e. questions of after-the-fact compliance, audit and fraud prevention. That's "downside management". You've also hinted though at "upside management", i.e. a focus on "how business really works". If BPM and accounting start dating again, then it can't just be about compliance and audit, however necessary. What do you think the upside wins could be so much bigger?
    The reply is currently minimized Show
  • Accepted Answer

    Friday, January 15 2016, 05:00 PM - #Permalink
    Resolved
    2 votes

    Our group is building a worldwide Kbase for a client in a narrow area of medicine where there will be 100 "evidence-based best practices" comprising 20-50 steps each.

    I would agree no more than something like 13 constructs, perhaps even less, will be needed/used.

    Our model has zero starting constructs - the end users drag and drop to a blank sheet and then, same as David, effect one click. End users do need help with rule set building.

    The users want to see bibliographic references, resutls of trials, research papers, grant sources plus feedback from the field before they agree to use a best practice.

    Bottom line, the Kbase has 100 protocols plus 4,000 related documents and because the users have no time to try to interconnect these in the many different ways that suit their changing needs, they expect to see/access everything at one graphic free-form search screen.

    The reply is currently minimized Show
Your Reply

Join the Discussion

Want to join the discussion?

Login, or create an account to participate in the forum.

Top Participants

Dr Alexander Samarin
277 Replies
27/09/2016
David Chassels
270 Replies
27/09/2016
Emiel Kelly
222 Replies
27/09/2016
Bogdan Nafornita
209 Replies
27/09/2016
E Scott Menter
182 Replies
27/09/2016