Resolved
3 votes

As Scott Francis wrote here: "So don’t start with data. Start with people and process and then use the business and technical requirements you discover along the way to define the data needed to support the process." What do you think?

Tuesday, February 09 2016, 09:51 AM
Share this post:
Responses (17)
  • Accepted Answer

    Tuesday, February 09 2016, 09:59 AM - #Permalink
    Resolved
    6 votes

    Goals should come before either ;-)

    There's always a problem to be solved, and the nature of the problem will tell you whether data or process should be the primary concern.

    • Scott Francis
      more than a month ago
      ah but the question wasn't what OTHER thing should come before those two things ;)
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 09 2016, 10:09 AM - #Permalink
    Resolved
    4 votes

    Interesting question and the obvious answer is process and outcomes or goals thinking comes first. However establishing the data structure is often a wise move before building the process that creates the operational data.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 09 2016, 10:13 AM - #Permalink
    Resolved
    5 votes

    Yes, sure. First, business objectives, then the processes to achieve the objectives, and then, required data to be treated along the processes. This approach based on a process architecture before going to the operational processes, allows us minimize overlaps between processes activities and related data, which means more efficiency in development time of enterprise applications, and also in business operation time.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 09 2016, 10:18 AM - #Permalink
    Resolved
    5 votes

    Scott makes a good point. By better understanding process and the people (role and responsibilities) associated with it you will better recognize and grasp the data needed to both complete the process and then improve the process/operations through reporting and analytics. Even experts often don't realize the potential of BPM-based solutions for reporting and CPI. They have never had access to real process data (touch time, turn around time) coupled with form data to fully improve costs, quality, and speed.

    The reply is currently minimized Show
  • Accepted Answer

    Tim Bryce
    Tim Bryce
    Offline
    Tuesday, February 09 2016, 10:36 AM - #Permalink
    Resolved
    3 votes

    Process and data go in tandem. First, you have to define information requirements which drives both.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 09 2016, 10:44 AM - #Permalink
    Resolved
    5 votes

    Process needs to come first, or at least in parallel as lots of people have stepped up to say.

    But don't forget data as many BPMN tools do.

    And yes, I know BPMN is not a synonym for BPM practice ;-)

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 09 2016, 11:11 AM - #Permalink
    Resolved
    5 votes

    I hope that architecture comes first before process and data. Then all depends, as usual.

    • Modelling/design – process first
    • Implementation / instrumentation – data first (actually data schemas)
    • Execution – process first
    • Monitoring – data
    • Measurement – data, data and data
    • Optimization – data, process, data, process, etc.

    Thanks,

    AS

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 09 2016, 11:11 AM - #Permalink
    Resolved
    5 votes

    What do you need in order to cut a tree? Probably muscle power and an axe (pre-industrial phase for example sake...). But probably also some knowledge so you know how to start cutting... And knowledge about which tree and which wood... The question is therefore a bit more challenging than you would expect.

    The how implies process. Doesn't matter if you're a complete beginner or seasoned lumberjack. The beginner lumberjack needs more information on the how than the seasoned one (hence why managing process knowledge is a tough gig :-)). Both need however information on tree thickness, amount of trees to cut etc.

    Data could be 50. But that doesn't do anything for me unless I have context. Context is: thickness in cm of the tree or the amount of trees...

    So... I think process is a good starting point. However you cannot do without data. And as the axe becomes blunt over time, I probably need KPI's here... In the right context.

     

     

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 09 2016, 11:23 AM - #Permalink
    Resolved
    5 votes

    This is a chicken and egg question. It starts with management setting goals. Hopefully they look at data, but they might use a scenario comparison process to do that. Processes and people need to be created to attain the goals, but data is leveraged and checked to see if goals are on track. Events and busines patterns are found in data, analyzed and in turn turned into rule and process adjustments that are either emerging or humming along. What comes first? They work together and are codependent. I've played the role as a process bigot, a rule bigot, an algorythm and a data bigot. Alone they are beneficial. The true multiplier effect takes place when they are used together :)

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 09 2016, 11:30 AM - #Permalink
    Resolved
    3 votes

    (this is a 1:1 copy of my answer to Scott's original post)

    Always good to questioning things. Personally I don't see data as something separate from process.
     
    What many define as process is what I see as the workflow of a process (what happens for a case?), so when designing a process you should take all kind of aspects into consideration (workflow, data, people, supporting tool stuff, the way a process is managed etc).
     
    But I completely agree that the result of process is more than data.
     
    Talking about data; one thing not to forget that, when talking about process, I see 3 levels of data:
    1. Case data (all the data of an individual case)
    2. Operational steering data (data to monitor the progress of all cases in the process)
    3. Process performance data (data that telss you how wel the process was designed to deliver what it promises)
    When rethinking this; I think I just agree with you as data is only one of the requirements to make a process perform.
     
    Happy processing!
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 09 2016, 11:57 AM - #Permalink
    Resolved
    2 votes

    Shocked by how many people start with goals.

    Think about how a company starts.

    First thing is something sells.

    Then we work out how to make more of these sales, cost-effectively.

    A company is born - a system for repeating something we have seen work.

    Systems are always paramount.

    Somewhere along the line, managers - people hired to manage existing processes - decided they knew better.

    So they created goals - their bet on where the company should go and what it should do.

    If you redesign the company's processes to suit these goals, you are buying into that manager's bets on the future.

    The key difference is that systems adapt, goals usually don't.

    This, of course is where data comes in.

    A system is as good as the data that drives it.

    Every step produces data. In wasteful systems that data is discarded.

    But in a good system, there is a virtuous loop - the data produced by the system is used to make a better system.

    That system has some assumptions at its core - that its end result is to produce more sales, more profit or more customers (often conflicting).

    But a goal is a whole set of assumptions put together into a single view of tnhe result. It has multiple points of failure - each assumption could be at least partially mistaken. Often a minot error at one point causes a catastroiphic result. And often the frigging of the system to keep it on track takes most of the company's effort.

    Think systems - not goals. For goals, read assumptions. And data is the rock they ar all built on.

    • Emiel Kelly
      more than a month ago
      I am shocked by how many people don't separate process result (ea a delivered pizza) and goal ( within 30 minutes)
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 09 2016, 11:58 AM - #Permalink
    Resolved
    3 votes

    As a rule of thumb: sure. Which is why it's odd that certain BPM products want you to build data models before doing pretty much anything else.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 09 2016, 12:02 PM - #Permalink
    Resolved
    3 votes

    In the Lean BPM philosophy the answer is 'neither'. In the lean BPM philosophy, business users will run 'processes' without thinking in formal terms like processes and data. By the time they start noticing recurring patterns, their existing 'processes' will have both process-elements as well as data-elements. If they go back and look at their proto-processes in retrospect, some would have started out with data and some would have started with 'processes'.

    If they do want to do some up-front design, then in that case, the answer would vary depending on circumstance. Some processes are more naturally modeled with a data-first mindset and some with a process-first mindset.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 09 2016, 12:19 PM - #Permalink
    Resolved
    4 votes

    As discussed over Twitter as well, yeah, imho process and data are inseparable --> just like so many other applied business constructs.

    Sure, if you look at the implementation methodology anything that floats your boat is your right answer. I've seen it succeed both ways so I don't really have a preference.

    Process discovery unveils the underlying data model but in so many cases it is the data model instances that lead your to-be process to branch out into unforeseen directions.I just do both at the same time.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 09 2016, 01:29 PM - #Permalink
    Resolved
    3 votes

    Perhaps it's not a coincidence that the "data first" posting which was the (negative) inspiration for Mr. Francis' excellent original question, came from IBM, IBM of course being the alma mater of relational database guru E. F. Codd.

    I concur with multiple comments that suggest data and process must go together, although from a technical perspective, data is logically prior. And if it isn't, bad things happen. The importance of data versus process (versus code) is even a sociology-of-IT question when, bizarrely today, relational database technology is not a given, but a question.

    From the sales perspective I will highlight the question of business case. Data and process models are infrastructure. There's no business case for operational infrastructure. No one really wants to pay for data modeling. Both data and process are about modeling reality; but before reality can be modeled it needs to be learned. Who will pay for learning reality? Lots of times it just doesn't happen.

    So given such challenges, how do we assure ourselves that our applications and our bridges don't fall down? As has been suggested, the devil is in the details. The win is sellling a project which enables incremental data and process learning. On this basis, it's possible to deliver new capability continuously, and then the funding will also be assured.

    • Scott Francis
      more than a month ago
      True there was a data first posting from IBM, but also a similar post from Appian, and another from Oracle :) Good stuff, plenty of blame to go around so to speak ;)
    The reply is currently minimized Show
  • Accepted Answer

    KM Mukku
    KM Mukku
    Offline
    Wednesday, February 10 2016, 01:35 AM - #Permalink
    Resolved
    3 votes

    Data begets Process begets Data. But, the process may not produce any data, of course not considering meta data about the process itself.

    Process begets Data begets Process. A process may not necessarily produce data, that is, a process may not beget data.

    This would suggest that we are not in the typical chicken and egg scenario. Too many ifs and buts.

    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, February 17 2016, 06:14 AM - #Permalink
    Resolved
    2 votes

    I think processes and data influence each others.

    If your approach start with a process you will be able to:

    • define datapresented to the user
    • identify dataneeded to drive the process flow
    • interact with external data storage systems
    • ...

    If you focus first on data, then you will be able to identify processes:

    • involved in data creation (e.g. new invoice process)
    • needed to update a data set (e.g. process that defines a team yearly budget)
    • ...

    So I would definitively suggest an iterative approach to build a solution in which processes and data are aligned.

    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
278 Replies
30/09/2016
David Chassels
271 Replies
30/09/2016
Emiel Kelly
223 Replies
30/09/2016
Bogdan Nafornita
210 Replies
30/09/2016
E Scott Menter
182 Replies
28/09/2016