We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

Which comes first, the content or the process?

Vote 0 Votes
A question that comes up in my podcast with Steve Weissman, and which he also covers in this blog post, so which comes first, the content or the process?

13 Replies

| Add a Reply
  • tut tut, the intended RESULT comes first and only then should you look at possible ways to achieve those results.

    What we generally call process is really nothing more than a wrapper around tasks whose only connection is their contribution towards the result.


  • Maybe I should explain my first response at bit more:

    The result is the WHY, which is already difficult enough, depending on your perspective. It could be what a process is able to deliver/achieve but it could also be what should be delivered/achieved. The first is the (usual) internal perspective, the latter could go as far as customer expectations.

    Next come the tasks required to reach the intended results, the WHAT needs to be done question.

    Then we get to the organisational bit, the HOW can I ensure that all the necessary steps (and only those) are taken in the right sequence by the right people etc.

    Of course, the WHAT and the HOW are not quite as independent, as you would ideally use one to challenge the other for continous improvement (given stable result expectations).

    Or am I taking a too simplistic view of things?

  • What comes first is the vision and discovery on how to execute it. I suggest capturing the following:

    -Project Overview and Objectives
    -Process Map (workflow)
    -Business Rules - Descriptions, Inputs, Responses, Participants, Responsibilities, Policies, Procedures, Deadlines, Routing, etc.
    -Form Specifications - Layout, Inputs, Outputs and Rules
    -User Experience
    -Reports and Dashboards - Design and configuration
    -User and User Group Configuration Requirements
    -Hardware and Server Specifications per Environment

    The above combines content with process to form a a project plan/scope to deliver a result that ultimately streamlines and automates your business.

  • I am sure that just about everyone (like in Steve's post) is going to answer "yes" or "both".

    I actually think that if you use process in its broadest sense (like I do for adaptive case management) - then process comes first. Content wouldn't exist if there wasn't a process to create it - yes the process may have happened long ago and far away, and probably was an unpredictable, unstructured process - but nonetheless - it generated the content.

    So for me - Process first, then content.

    Jacob Ukelson - CTO ActionBase

  • Some Enterprise Architects out there would have you believe that you can interpret the process by analysing the data (documents, systems).

    This is rather like trying to work out what a diner had for dinner in a restaurant by exploring the contents of their stomach. Far simpler to simply ask them - or look at the menu.

    So work out what the process first and then the supporting content becomes obvious - with the benefits that duplication of content can be removed (i.e. people using different versions of examples of forms or using applications in different ways).

  • Optimally, you start out with a clear understanding of the content you will need to manage and how it will be consumed. Then you should define processes upfront to ensure the content is easy to search, navigate, manage and has clear ownership. However, it's more common that the content grows to a point where it's unmanageable and then processes are introduced as an intervention. Processes should but don't often come first.

  • There is a lot of historical information on the enterprise that can be brought together through BPM. This data already exists, but is it content because it may not be usable in its existing form without BPM? For sake of argument, let's say "yes, its content that already existed first". Now the BPM model is created and is runtime executing, generating new content from processes such as "Order to Cash". In this case, the process model was created before this new content got generated. The value of the newly generated content is it will exist off-the-shelf as usable content to the business, that won't need to be integrated like the historical content requires to be usable to the business.

    The only caveat to my answer above is it depends on your definition of the word "content" and whether its more data oriented (requiring manipulation to be usable) or Information oriented (not requiring manipulation to be usable to the businss).

  • There are some courts (all of them) who judge if some processes were legal or not by following the paper/email (content) trail. No content, no trail.

    I said in 2000 and it is still as correct: 'There is no process without content and content without process you can delete.' Before we had BPM software the process was all content ONLY!

    There are those who believe that you can ask people to describe their work and then you know the process. As if I could become a master chef by reading the cookbook of one. Looking at the menu tells you nothing about how the food tasts. It is obvious that process DOES NOT guarantee OUTCOME. You ask people about the same food and you get very different opinions and experiences. But I can ask people if they liked it and then I know that my goal has been reached. It is the skill and experience of people that create perceived value in other people.

    Processes may create content, but actually there is a lot of content that arrives in a business and has the problem to find the right process and there is much more content created without defined process (emails and MS-Office) than defined in processes. And no, those processes can NOT be flowchart automated in most cases.

    Yes, email creates the problem of duplicates, vesions and lost content. But that does not mean that all this content can be enforced through a rigid process, making the perfect case for ADAPTIVE processes that allow people to link data, rules, resources and GOALS into content, or link content to data, rules and goals.

    Garth's description misses the definition of content at all. Content is not GUI forms. Some of it may be replaced by such, but in most processes content (image and composite) objects and their states are the key drivers of progression. Most business people have a serious problem to create the description that Garth asks for. Therefore the gap between reality and process illusion.

    Most business people have no problem to describe what content they work with and how. Give them a well architectured adaptive process infrastructure and let them receive/create/modify content freely to fulfill process goals and they will be quite effective and over time they can become more efficient through the transparency created.

    Once you see how performers work you can start to verify objectives, outcomes and targets and perform collaborative guidance through process owners and customers in realtime.

  • Frankly, I think we should split the discussion at two levels:
    - at the modeling level
    - at the instances level

    At modeling level, I think that content may come first, in the sense that you may first design your content model/schema; while the process model can be built/mined either before, in parallel, or after that (except for some content that depend or describe the intermediate process states).

    At the instance level instead, good practice imposes that the processes lead to the content definition and usage.

    • Marco, I do not understand your reason for suggesting to consider models and instances differently.

      The models should only provide the component templates for processes and content. The instances of both should be created by the business users. Content state changes of a variety of possible objects will actually drive the process forward. Rules can deal with the dynamics of content events while flowcharts fail miserably. So we can work towards a process goal without flowcharts, but not without content or rules.

      • Hi Max,
        you actually support my point with your comment.
        The "model" part, be it a workflow, a set of rules, or some content model, is one thing. This is typically done by analysts/designers.
        Its instantiation is another and is actually performed by business users.
        My point was that for the discussion we need to split these two worlds because the times and processes can be dramatically different between the two.

  • Ah, I may have put a completely different meaning into 'content' in my earlier postings.
    Note to self: Semantics are just as important as content.

  • The answer to this question depends also on what we consider to be better covered by today's tools.

    My appreciation is that we have a lot of tools to store/retrieve structured data and content: databases, data warehouses, content stores, enterprise applications, knowledge bases, search engines etc. Processes coverage lags far behind hence we should target them first.

Add a Reply

Recently Commented On

Monthly Archives