Thought Experiment on Snippets

Many conversations on Adaptive Case Management follow a similar pattern: start by agreeing that (1) a context to associate all the information for a case is good, (2) there is a need to represent goals, (3) a need to assign tasks to people for notification /reminders, and finally (4) the suggestion that the case manager will need pre-defined process snippets to use in the case.  The argument is very logical: why force the case manager to draw up the process every time when you could create the process snippets in advance, and at run time just use them.  This logic is flawed and this long post is an attempt to explain exactly why.

Every description of Adaptive Case Management includes the idea of process snippets: small pieces of process that you bring to bear when needed while working a case.  A process is a sequence of tasks, possibly with an order for those tasks to completed, and possibly with some logic to branch through the tasks.  Most people imagine a process snippet as being 4 to 7 tasks, but in principle it could be any size.

The idea is that a process snippet will be created in advance and then stored in a library of snippets.  As a case manager, when you find yourself in a situation that needs a particular process, you bring that snippet from the library into the case.  When the snippet is brought into the case, there is a certain amount of work to hook the snippet up to the case, such as for example the association of specific people working this case with specific activities in the snippet.

It should be obvious to everyone that the value of pre-defined snippets is directly related to how predictable the case is.  Some cases will be very repeatable, and pre-defined snippets will be useful.  There is an systematic unintentional bias toward thinking that work is more predictable than it really is.  It is easy to think about the things that I do the same way multiple times, but it is very hard to think of all the things that are done differently every single time.

I will argue, that in a large percentage of the knowledge work cases, preparing the snippet by modeling it, together with the hooking the snippet to the case, will be more effort than it is worth.  In other words, in many cases it is simply not worth modeling the snippet up front, it will be easier to just create the process from scratch when needed.  Instead of focusing on tools for modeling snippets in advance, we should instead focus on tools for creating the exact process when needed.

Argument By Analogy

I will have to lay out this argument carefully, so please bear with me — it is a long post.

We need to remember that knowledge work is often very creative.  Don’t think about the work of a desk clerk or a receptionist as example.  You need to think about examples which are highly creative and highly innovative.  You need to think of an artist, or a poet, or an executive, or a corporate board member, or a writer, or an inventor.  Knowledge workers are more like Sherlock Holmes, who has to figure out each step just before it is taken.  Yes, every knowledge worker also does very routine things, and that can be supported by a host of traditional technologies — ACM is specifically needed for handling the creative, innovative, and unpredictable work that those other technologies can’t handle.

Lets use “writing” as an analogy to knowledge work, because it has the same kind of creativity.  A writer, during the act of writing, is creative &  needs the flexibility to make decisions about what is and is not going to be written.  I would say that a typical knowledge worker needs the same kinds of creativity about goals and plans that a writer needs about what is being written.

The main tool of the writer is a “Word Processor” of various forms.  This blog has a simple word processor built into it to support the writing of blog posts.  For this analogy, we will compare the kinds of flexibility that a wordprocessor gives a writer, to the kinds of flexibility that ACM gives to a knowledge worker.

Think for a moment about a writer sitting down and creating a set of articles, or a set of various works.  What does that writer need?  What feature can you offer to make the job of a writer easier?

Imagine that you are in charge of designing a new word processor to help that writer perform their work.  You already have the ability to type, text formatting, layout, pagination, merging of graphics and text, etc.   The analogy to “process snippets” is “a predefined library of sentences, or paragraph fragments.”

The logic goes like this: any writer who writes consistently on a topic will naturally want say the same thing again from time to time.  Maybe not exactly the same way, but substantially similar.  What the writer could do is to prepare in advance some sentences or paragraph fragments that could be brought into an article at the time it is needed.  This would save the writer effort at the time of writing.

The argument for predefined blocks of text is the same as the argument for predefined process snippets.  There is no question that writers are repetitive — including yours truly.  Clearly, preparing sentences in advance would save effort at the time of writing.  Why then do writers not do this?  What is the flaw in this logic?

If you read through my blog, you will undoubtedly find sentences that are repeated.   Beyond the blog posts, I write emails to people, comments on others blog posts, articles, book chapters, white papers, reviews, etc.  In those, I often need to make very similar points.  Shouldn’t I have a library of sentences to re-use?  Wouldn’t it make life easier to just pick prepared paragraphs and past them in, instead of having to tediously type them out?  Typing is work, pasting from a library would save me work, therefor, I should have a prepared library of sentences and paragraphs to save me time.  There is a flaw in this logic, and it is the same flaw in the logic that say people will prepare libraries of process snippets.

Later, I will show that writers do reuse text without preparing libraries of sentences in advance.  That method of reusing earlier work is entirely different.  First, I need to cover some cases where writers do actually create blocks of text in advance, so we can explore those situations.

Mail Merge

It is easy to imagine that a business person needs to send formalized correspondences to people that substantially similar: we call this a form letter.  Word processing programs often include “mail merge” which is a capability to take a template with specific fields within it, that are then substituted with values from a database when output.  This allows the generation of hundreds of form letters that are all the same except for the name, address, and a few other details.

A “mail merge template” is a block of predefined text that is then reused at run time.  One might easily imagine a business person sitting down to decide all the different types of forms letters that would be needed for a particular process: application rejection letter, need-more-details letter, acceptance letter, etc.    A mail merge template for the writing world is very much like a predefined process snippet for the knowledge worker.

Notice however that we have drifted from a discussion of writing, to a discussion of a routine, predictable business process.  Clearly a student loan application process needs form letters, no question about that.   But do writers use mail merge?  Have you ever seen a magazine article, or a blog post which was produced using mail merge?  Of course not, there would be no point.  A form letter is not an act of creative writing.

Even when the task of writing is very routine, few business people actually use mail merge to produce form letters.  Logic says one would save work by defining a template in advance for the letter you are going to write, and then using the template at run time, but the flaw here is that it is very difficult to create a mail merge template that can be used successfully.  You have to think hard about all the possible situations that the letter will be used, about all the possible variations of data that will be incorporated.  You have to think about how clean the data is, and how much you can trust different DB fields to contain the right information.  Will the letter contain only US addresses with a 5-digit zip code, or will you need to include UK-style postal code with letters and numbers, or European style which is placed before the city?  You have to test the template carefully to make sure  everything works right.  When using a template, there will occasionally be errors in the data or the template that will need to be addressed at run time.  Creating a mail merge template is a programming activity.  You have to be a programmer to make a mail merge template.  Most business people, most knowledge workers, are not programmers.  That is why office workers hardly ever use mail merge capabilities of their word processors.

Most office workers will instead take a copy of the last letter they wrote, and then edit it for the new situation.  There are huge advantages to this.  First is, when you write the first letter, you don’t need to think about all the possible variations … you think about only this letter.  When you copy the letter, if the situation is different, it can be changed.  When entering the new address into the letter, you can format the address however is needed.  And there is no testing involved: you edit the letter until it looks right, and then you print.  In the long run they will spend more time editing letters, but this is spread out over time, and they don’t need to invest a huge chunk of time up front.

Neither the routine office worker, nor the highly creative writer, are going to use predefined mail merge templates for their work.  For writers, it should be obvious that the amount of variation in what is being written is far too great to consider mail merge even being helpful.  The time spent to make a reusable template, even for a point that the writer makes all the time, is too much up front work.  It is far easier to simply copy from an earlier sample of writing.

The situation is the same with a knowledge worker with regard to process snippets: To make a reusable process snippet, some significant effort is required to think about all the different ways that a process snippet might be used.  You have to consider an aggregate of cases, and what is needed.  And then, similar to the mail merge fields that are embedded, you need to extend the process with some form of mechanism that can pick up information from the case instance and use for things like assigning task responsibility to the right person.  This is often done by defined “roles” which are reusable bundles of people that define a relationship to a set of activities, so that a person can be assigned to a role instead of the activities directly.  But the case instance will have to be prepared with the roles defined, for a process snippet to use them.  Preparing a reusable process snippet is a non-trivial amount of work beyond simply entering the tasks to be done.  For non-routine work, that extra work is simply not worth the trouble.  It is easier to simply make up the process as you go, and then to simply copy fragments from earlier cases and edit them.

Quotations

A second area where a writer might use pre-defined text is that has to do with quotations.  A quotation is a predefined sentence, attributed to a particular person.  Often the quotation is saved in a kind of library, so that it can be re-used in future works.  Those who use quotations know the effort required to store and then later find such quotations.  The value of a quotation comes more from the attribution to a famous person, and not from the fact that it saves you typing.  If all you wanted to do was make a statement, it would be far easier to just type the sentence, than it is to go an find the quote to copy it.

That is the key point here: quotations are decidedly not used as a way to save effort during writing.  Every writer knows that it is quite a bit more effort to find an appropriate quote and accurately reuse it.  Furthermore, most writers do a web search for a quote at the time that they needs it, and do not actively maintain libraries of quotes they might use in the future.

Similarly with process snippets.  There will be times that a knowledge worker will seek out a particular process from a notable authority, and copy that into the case.  That is, however, a very different action from preparing a library of process snippets in advance, and the value is NOT one of saving effort, instead it will be from the authority of the source of the process.

Writers don’t prepare a library of text blocks in advance

Logic says that such a library would be useful, but I have never seen a writer who uses such a library.  The reason should be obvious to everyone:  the effort of finding that sentence combined with the effort of adapting the sentence to the current work, is greater than the effort of simply typing a new sentence from scratch.

The utility of a library of predefined sentences depends upon the amount of creativity a particular writer requires.  For example, if a writer needs only 10 sentences, and knows that all future writings involve combinations of those 10 sentences, then by all means a library makes perfect sense.   Insurance companies use this approach to send long documents to clients, where the document is actually a sequence of pre-written paragraphs, which are then selected and assembled according to the specifics of that that client’s policy.   Clearly the idea of a pre-defined library of paragraphs is useful in this case, but we all understand that this kind of document composition is not really what we mean by “writing.”  This is a routine, formal business process, not the creative act of writing.

How Writers Reuse Text

There is a huge difference between “pre-defined sentences” and “reusing sentences.”  A very common technique is for a writer to go back to a previous work, and copy large pieces into a new work, usually with some additional modification to update it for the current work.  If you read my chapter in the new Social BPM book, you will be able to find ample evidence of 8 to 10 of my blog posts in there.  Similarly, my keynote presentation at the Social Business Forum included extracts from that chapter.

So text is very often reused, but it is NOT the case that text is prepared in advance for the purpose of being reused.  A writer will write an article.  Then later, in the course of writing another article, will reuse text from the earlier article.  And so on.  The writer never sits down and declares “here is a set of sentences I am planning to use in the future.”  Instead, the act of writing is purely for the goal at hand to produce an article.  Later that writing might be reused, but there was never a specific act of preparing text that might be reused in the future.  And when text is reused, it still needs editing to fit the current context, and this editing is done in a way exactly like editing of brand new material.

In spite of all the powerful intelligent technology that could be put into a word processor to automate and “simplify” the act of writing, the fact is that most writers, when they set to write a piece, sit at a keyboard and type characters, to compose words, to compose statements.  Because the writer is so creative and flexible, a very simple interface of just typing letters, is the preferred way of composing a real article.

Back To Knowledge Work

Let me remind you that writing is used here as an analogy to knowledge work, and I am comparing the act of writing to the act of managing a case.   Writing can also be knowledge work, but understand that the analogy is to compare the tools to support writing with the tools to support knowledge work cases.

A knowledge worker needs to be able to create new and innovative tasks on the fly as needed, because as Peter Drucker said: “A knowledge worker is a person who knows his or her job better than anyone else in the organization.”  Constraining a knowledge worker to choose from a set of predefined tasks would not allow them to apply their expertise to the case.  Each knowledge worker knows their own business better than anyone else, so there is no one else to write those process snippets.

Since it is more work to create a reusable snippet, and because you need to be a kind of programmer to do this, most knowledge workers will simply create the process as a task list as they work.

The act of defining tasks is something that a knowledge worker does as part of work, just as the act of composing a sentence is part of what a writer does.  First a foremost, the system to support knowledge work needs to allow knowledge workers to define these tasks without restriction.

One of the biggest mistakes that people make when thinking about Adaptive Case Management is to think that knowledge workers will use a separate tool to define the task or process.  This will not work.  The knowledge worker is focused on their profession, not on programming.  The process has to be created directly from them doing their work, not from them going to a different tool and laying out a plan.

A knowledge worker may reuse processes from the past in the same way that a writer will reuse text from a previous article, but rarely will those be used verbatim.  In all cases the knowledge worker needs to be able to edit the process snippet with all the capability as if creating the snippet from scratch.  There can not be a one tool to prepare the snippets, and a different, less capable tool, to use them.

Predefined processes can be useful in the way that a predefined mail-merge template can be used for producing form letters, but few knowledge workers will use predefined process snippets in the way that few office workers use mail merge.  Reuse is really about going back to earlier cases, copying, and then editing to get the new process for a new case.

A library of process snippets is useful in the same way that a library of quotations is useful to a writer.  But a very small amount of the time is spent actually doing this, and the benefit has nothing to do with saving the work of typing.

Reflections

Discussions of Adaptive Case Management focus too often on predefined process snippets.  Snippets exist, but the are unimportant, in the same way that mail-merge templates are unimportant to a writer.  The focus on predefined process snippets detracts from designing something that a knowledge worker uses on a daily basis to get work done. Far more important is a focus on how knowledge workers can define processes emergently as they do the work, and to be able to copy what they did previously for reuse.  In ACM, there must be no separation between planning and working, instead you are always planning while you work.

The OMG currently has an initiative for “Case Management Process Modeling.”  I have a great deal of respect for the people involved, and would wish them to be successful in what they do, but in this case the very basis of the initiative is wrong headed.  The goal of the initiative is “meta-model extension to BPMN 2.0 (Business Process Modeling and Notation) to support modeling of case management processes.”   A doctor is never going to model his own work processes in BPMN.  An executive is never going to draw up a BPMN diagram of the decisions he is going to make later that day.  Neither of these will be able to use processes modeled by someone else.

Think by analogy to the world of writing, what OMG is trying to do is to define “mail merge templates” that allow for powerful reuse of blocks of text.  Mail merge is a kind of programming, and the OMG is a group that focuses on powerful techniques for programming.  But I have pointed out sufficiently, that a writer will never use a mail merge template.  For exactly the same reason, a knowledge worker will not use predefined process snippets, especially if they are defined using BPMN.  The initiative members are simply barking up the wrong tree.

Knowledge work is creative and innovative, and as such is unpredictable.  Modeling can only be used when the process is predictable.  Modeling, which is all about predicting what you are going to do, is useless to a knowledge worker who figures out what to do, when they do it.  Correction: I don’t mean to say that predefined snippets are useless.  What I mean to say is that the effort to predefine a reusable process, combined with the effort to map that process to the particular situation, is greater than the effort than to simply create the process when needed exactly as needed when needed.

I have been asked a number of times to help with this OMG effort, and I have declined.  If the initiative could be changed to not be about modeling, to not be about BPMN, and to not be about predefining snippets, then I would be happy to help.  However, the charter of the group is explicit on these points.

My wish for my friends at OMG, is that they will see that what they are trying to do is really a kind of BPM, and not case management at all.

Advertisements
This entry was posted in Adaptive Case Management and tagged , , . Bookmark the permalink.

13 Responses to Thought Experiment on Snippets

  1. rotkapchen says:

    It seems there’s a struggle here with a paradox that needs to be embraced. Indeed, there are scenarios for which parts of it can and should be turned into algorithms and binary code. But as the algorithm itself teaches us — at some point there are too many variables for which the human element needs to apply their own just-in-time heuristic and mystery strengths (see graphic models included http://totalexperience.corante.com/archives/2010/02/28/design_thinking_in_stereo_martin_and_brown.php)

    The law of the paradox is that somewhere there is a ‘both’. What you describe is a rational railing against a world stuck in the algorithmic/binary code bias. But we have to be careful not to throw the baby out with the bathwater.

    A lesson I learned years ago at the onset of object oriented theories, the value is not in the parts, but in the assemblies. In major initiatives, it wasn’t the small stuff that could be reused, it was major assemblies — functions that are common to many activities. In this case I was at MCI, a common function across many different applications was name and address processing/scrubbing. By creating a ‘lowest common denominator’ function, other apps could start with the function and modify it for specific contextual issues.

    Design deplores a ‘blank page’ and loves working with constraints. The goal isn’t (as many might assume) to predefine everything — it’s impossible. But there is tremendous value in starting with a ‘template’ — an artifact that helps remove all the mindless effort to put basics in place — something that gets you part of the way there.

    The challenge is simply stepping back and having the design/architecture insight to determine what those ‘key’ artifacts might be and just how ‘lowest common denominator’ they can/should be created.

    • kswenson says:

      Very interesting points and references. I have carefully segregated the goals: routine work can be supported by traditional approaches and those traditional approaches must not be thrown out. I focus instead on the things that can not be done “with algorithms” as your referenced article suggests. I like the idea that “design thinking” needs to be more pervasive and integrated with work, instead of the old approach where design was segregated from work, and done by different people. I will have to read up more on this.

  2. Pingback: Thought Experiment on Snippets (via Collaborative Planning and Social Business) « Ovations Group Blog

  3. Pingback: links for 2011-07-01 « steinarcarlsen

  4. Pingback: BPM Quotes of the week « Adam Deane

  5. Fred Cummins says:

    Keith,
    Before I discuss your thesis, I need to clarify the nature of the OMG effort to develop a case management modeling standard. We are not defining an extension to BPMN. That may be the goal of some submitters, but it is not a requirement of the RFP and it is not the goal of my submission team. We recognize that there may be times in the management of a case when a BPMN process will be engaged, and there may be times when a BPMN process will initiate case management, but these are distinct disciplines. There will also be some people who want to work on both BMPN processes and case management, together, because they interoperate. There will also be managers that want to buy one tool for modeling both. We will try to achieve compatibility without sacrificing integrity of the solution.
    As for your thesis, your analogy is interesting but not particularly relevant for several reasons:
    • You describe an individual task while we consider case management a collaborative activity. You are describing task management. We are describing collaboration management. Examples: customer support, patient care, product development, business transformation, process improvement projects.
    • Fragments (your snippets) are not inflexible structures but are adaptable patterns. Case workers are free to change them or to ignore fragments and work from scratch. However, extending your analogy, when authoring with others, there is usually a plan of assignments where each author has a sequence of tasks for their section that includes reviews and edits by others along with other actions to finalize their section. These patterns could come from a pre-defined fragment. A fragment may also be quite comprehensive such as the work breakdown structures found in application development methodologies. It provides a structure and a lot of useful detail the project manager may selectively add to or delete.
    • Case (knowledge) workers are typically working on multiple cases at the same time. They need to coordinate their work on each case with the work of others, and keep track of where they and others are on each case.
    • The case typically evolves independent of the efforts of the knowledge worker, so events must be recognized, possibly filtered and acted upon when they occur. When actions are not taken in a timely fashion, an alert should be raised. These event listeners can be built into reusable fragments and tasks.
    • Reusable fragments and tasks are more like your author’s words. You define “snippet” once and reuse it many times here and in other writings, conveying a specific concept. Predefined fragments and tasks include links to relevant information and define the content of inputs and outputs.
    • Connecting tasks and fragments into a plan should not be as burdensome as it might seem. Many fragments and tasks will be brought in because they are needed now or need not be delayed, and so they are immediately actionable. Others require a simple connection of an arrow to a task that is a prerequisite.
    • Roles should be defined for the type of case, and the nature of the task should determine the appropriate role to perform it. Most roles of a case should be assigned to individuals at the beginning of the case and re-assigned as needed.
    In summary, I believe that collaboration is a major factor in knowledge work, and thus I don’t believe we are solving the same problem.
    Fred Cummins

  6. kswenson says:

    Fred,

    Thanks for responding. The first sentence of the RFP is “This RFP solicits proposals for a meta-model extension to BPMN 2.0 (Business Process Modeling and Notation) to support modeling of case management processes.”

    That first sentence … that is where I get completely confused. It says that it is for an extension to BPMN. You say “We are not defining an extension to BPMN.” I just get really confused by that.

    There is something about the way that the first sentence says “This RFP solicits proposals for a meta-model extension to BPMN 2.0 (Business Process Modeling and Notation) to support modeling of case management processes.” that just leads me down the path of thinking that the RFP is actually soliciting proposals for extension to BPMN 2.0, and that the purpose of the extension is to support modeling of case management processes.

    Maybe I am just confused about that sentence …. could you explain it?

    • Fred Cummins says:

      Keith,

      I’m sorry that you were misled by that sentence. Extending BPMN was an issue under discussion during the drafting of the RFP, That sentence should have been changed. The controlling requirements are stated in Section 6.5, and do not require the solution to be an extension of BPMN.

      Of the three submissions, ours is clearly distinct from BPMN. The IBM, Oracle, SAP, Bizagi submission has aspects of leveraging BPMN, but states that the specification is intended to be separate. The submission from Singularity does take the approach of extending BPMN. We expect to explore the possibility that a tool vendor might implement case management as an extension to their BPMN tool, while the specification would also enable another tool vendor to implement only case management. This would enhance industry appeal of the specification.

      Nevertheless, I believe modeling in BPMN will be a distinctly different discipline from modeling for case management. Furthermore, the work of an author in developing a document, as you discussed, is distinctly different from a collaborative effort, particilarly where each participant may be engaged in multiple collaborations. At the same time, we should consider how we support each individual in managing their individual work as part of the overall environment. As you suggest, this may be more a matter of runtime/implementation facilities than modeling.

      • kswenson says:

        Section 6.5 says:

        6.5.8 Notation
        Submissions shall provide a graphical notation that complements BPMN notation
        and supports the additional modeling elements and constructs.

        6.5.9 BPMN Metamodel Reuse
        Proposals shall reuse elements of the BPMN v2.0 metamodel where appropriate.
        Where an apparently appropriate concept is not reused, proposals shall document
        the reason for creating substitute model elements.

        6.5.10 BPMN 2.0 Extension Mechanism
        Proposals shall use the extension mechanism provided by BPMN v2.0 to the
        extent that it is compatible with the intent of the proposal. If the extension
        mechanism proves to be incompatible with the intent of the proposal, the
        proposal should explain the problem.

        “explain the problem”???? “reason for creating a substitute”??? Forgive me, but there is a high modeling orientation to the strict requirements. Here is my concern: I could put a lot of effort into a contrary proposal, only to have it shot down by someone saying: “you have not given a good enough reason to deviate from BPMN.” Given the profound bias toward modeling / programming, I would find it a high risk that I would be wasting my time. What guarantee would one have that a contrarian approach would be accepted? The question, of course, is who would be “deciding” and since a majority of the judges think that a BPMN approach is appropriate, what reason would they have for doing something else?

        What is missing from the RFP is the desciption that the way of expressing will be suitable for non-programmers. In fact if you read it, every paragraph has a strong programmer orientation to it.

        But section 6.5.8 is a clencher. Is say, quite clearly, that you HAVE to provide a graphical notation that compliments BPMN.

        6.8 Evaluation Criteria – Submissions will be evaluated base on the following criteria: Compliance with requirements

        Section 6.8 makes it clear that a non BPMN approach will fail the first of the evaluation criteria.

        Either the RFP is meaningless (in which case my HDR photography proposal would be equally good) or it would be extremely risky to propose a non-modeling, non-predefined, and non-BPMN approach. My time is limited. Why would I waste it trying to convince the people who produced an RFP that their RFP is wrong and needs to be changed? I am not that naive.

        Change the RFP first, and then I would consider helping.

  7. Fred Cummins says:

    Keith,

    The bias you sense in the RFP is typical of the bias we face in the industry. Development of a standard (the process as well as the result) will help overcome that bias and give legitimacy to the products that implement the standard. I believe the potential market is a multiple of the BPMN market, and a standard will be a catalyst for grpwth of demand. I think healthcare represents a particular need and opportunity to have a major impact.

  8. Henk de Man says:

    Keith,

    Tasks aren’t like text snippets. In enterprise world, design of tasks requires technical work, such as defining (or re-using) forms, web-services, etc., inputs/outputs and their bindings to a logical case information space (call it “case file”), pre/post conditions (possibly), setting execution rights, etc. Once defined, in relation to e.g. a case type, the knowledge worker can consider to use them when and where appropriate. This involves selection, creating one or more instances, assignment of case instance data elements (where e.g. the design time binding only results in a collection in run-time), etc.

    Consider these pre-def tasks “atomic” “snippets”. But this is not the total picture.
    In enterprise world, there are other concerns too, like: methodology compliance, best practice, standardization and regulatory compliance. These can lead to definition of “snippets” that are “composite” (though often still adaptable..). E.g. a task, followed by a review task, or a task that depends on another task to be done prior to it, etc.

    Picking “snippets” to become part of the plan (i.e. “to plan” them), need not be difficult.
    Think about a product development case (e.g. in SCRUM). You want to plan a task for some-one, to create a process model, against one or more product requirements or stories. The task is predefined. It comes with a link to the process modeler application in the right work space, mapped to the right SVN/namespace. It comes with defined inputs, such as a location where the requirements/stories are stored, as well as with defined output, being the location from where a reference will be required to the newly to be created process, etc. And when this task-as-defined, is picked, an instance is created on the fly, it is added to the plan on the fly, and when it is required that a sub-selection of requirements/stories should go with it, interaction is possible to pick some of them. And then the instance is assigned to “Joe”.

    And yes, when methodology or best practice requires, probably the “snippet” was not just an individual “design process” task, but possibly one that is followed by a review task. Of course, any dependency that is required can be created in the plan directly as well (e.g. as SCRUM masters often do..).

    The simplest of the simplest tasks is maybe one that only requires a form that is used to enter a text block, and maybe in addition, check some other fields. But even this form (the task actually) should be predefined, as no case worker in run-time will first design his/her tasks before he/she can use it..

    I trust you recognize that these needs are evident. I also trust that you recognize that, though we talk about very basic things here, BPMN is not the right paradigm to support what I just sketched her. A more straightforward, flexible and adaptive “work management” paradigm is required, and our CMMN submission (together with Fred and others), meant in response to the CMPM RFP, aims for that.

    You are still invited !

  9. kswenson says:

    This comment is from Henk de Man, one of the true visionaries in the field of case management. For some reason the blog software did not attach his comment, so I am adding this for him.
    ———————–
    Keith,

    Tasks aren’t like text snippets.

    In enterprise world, design of tasks requires technical work, such as defining (or re-using) forms, web-services, etc., inputs/outputs and their bindings to a logical case information space (call it “case file”), pre/post conditions (possibly), setting execution rights, etc.

    Once defined, in relation to e.g. a case type, the knowledge worker can consider to use them when and where appropriate. This involves selection, creating one or more instances, assignment of case instance data elements (where e.g. the design time binding only results in a collection in run-time), etc. Consider these pre-def tasks “atomic” “snippets”.

    But this is not the total picture.

    In enterprise world, there are other concerns too, like: methodology compliance, best practice, standardization and regulatory compliance.

    These can lead to definition of “snippets” that are “composite” (though often still adaptable..). E.g. a task, followed by a review task, or a task that depends on another task to be done prior to it, etc.

    Picking “snippets” to become part of the plan (i.e. “to plan” them), need not be difficult.

    Think about a product development case (e.g. in SCRUM). You want to plan a task for some-one, to create a process model, against one or more product requirements or stories. The task is predefined. It comes with a link to the process modeler application in the right work space, mapped to the right SVN/namespace. It comes with defined inputs, such as a location where the requirements/stories are stored, as well as with defined output, being the location from where a reference will be required to the newly to be created process, etc. And when this task-as-defined, is picked, an instance is created on the fly, it is added to the plan on the fly, and when it is required that a sub-selection of requirements/stories should go with it, interaction is possible to pick some of them. And then the instance is assigned to “Joe”.

    And yes, when methodology or best practice requires, probably the “snippet” was not just an individual “design process” task, but possibly one that is followed by a review task. Of course, any dependency that is required can be created in the plan directly as well (e.g. as SCRUM masters often do..).

    The simplest of the simplest tasks is maybe one that only requires a form that is used to enter a text block, and maybe in addition, check some other fields. But even this form (the task actually) should be predefined, as no case worker in run-time will first design his/her tasks before he/she can use it..

    I trust you recognize that these needs are evident. I also trust that you recognize that, though we talk about very basic things here, BPMN is not the right paradigm to support what I just sketched here. A more straightforward, flexible and adaptive “work management” paradigm is required, and our CMMN submission (together with Fred and others), meant in response to the CMPM RFP, aims for that.

    You are still invited !
    Regards,
    Henk de Man, Cordys

  10. Pingback: BPM Quotes of the week | Developers Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s