BPM.com
  1. Peter Schooff
  2. BPM Discussions
  3. Tuesday, June 10 2014, 09:41 AM
  4.  Subscribe via email
Scott Francis disagrees with the following Appian quote in this blog:
Without the data in place, what are the processes you can put into place? The key is to first start with the data and analyze, then working your way back to what you want to build.
What do you think?
John Tesmer Accepted Answer
Data is an artifact of a process, however broken it may be.

You may have a hard time getting meta-data - data about the processes which generate the data. But those times are changing as a direct result of ERP implementations over the past 2 decades. That's kind of what the "big data" industrial complex exists to do: review data from processes to help you find out information about the process as a whole.

Now you have people making decisions about processes based not only on the direct output of the process - the results - but on the data about the process - almost the first derivative of the process data if you are so inclined.

But this is not what he's talking about - he's talking about the entity data - the data on which processes operate and the transformed output of the processes. The "feedstock" and "outputs" to put it another way.

And I disagree with him on this. Processes exist to transform things. If you don't define what is to be transformed and what you want it to look like when you're done, then you're designing a process for process' sake.

In my opinion, they're both wrong. You have to begin with the end in mind. What are you trying to accomplish? What is the linkage to strategy? Perhaps at engineering levels you can focus on process first - i.e. when the data you receive are well defined already and you have a well-prescribed output. But even then, it should be an iterative process.
Comment
A process is an execution of steps that might do something with data. However, it is not necessary - doing with data. Data can exist on its own (after creation) with no processes around. A data may be _used_ as an artifact of a process, is not the artifact of a process.
  1. Guest
  2. 2 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Scott Francis Accepted Answer
Blog Writer
Chicken and Egg question: If data comes first, how did it get there?
Comment
Indeed. I boiled this egg in my response (see below).
  1. Guest
  2. 2 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Shelley Sweet Accepted Answer
Blog Writer
It depends… I think you need data right up front as part of the process selection and charter to see if this process is doing 'well' or not, and how high on the priority list it is. But as you start working on a specific business process improvement project (after the charter) it's really helpful to have the As Is model to put the data against. Of course, both are important!
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Max J. Pucher Accepted Answer
Blog Writer
Actually? Neither. What comes first is not the process nor the data but goals and outcomes. They decide what content is needed. The content drives the data and the process is what happened until you reached your goal. Data is most certainly not an artifact of process. Remember that processes do not exist but they are invented. Data is an artifact of content and content represents the process.

From a real-world perspective CONTENT is central but it makes no sense to decide what comes first. If you don't have content you have neither process nor data. Just data and process do not do anything practical. To make processes work the content is often encoded into forms and dialogs usually making it a lot more complex than it was without IT support.

There is no process without content and content without process (meaning goals) is waste.
Comment
I over-simplified my response to the "figure out all your data before you design your process" positioning. Obviously data definition doesn't wait til you're all finished with process. But neither should understanding the process wait until after you're all done defining the data...

Understanding context, process, and outcomes basically defines the requirements for your data definition, capture, and maintenance. (discussion with Emiel in the comments of the blog post helped clarify - because when I write about "process first" I assume that starts with outcomes because that's how we approach process... but it should be explicitly stated in forums like a blog post)
  1. Scott Francis
  2. 2 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Jose Camacho Accepted Answer
First, the business strategy to set goals.
Second, processes, or sequences of activities aimed at achieving the objectives.
Third, identify the inputs and outputs of activities over the E2E processes as macro entities (e.g., supplier data, client data, order data, delivery data, etc.).
Fourth, compile the macro entities and define data models required by processes to run at the most elementary level.
Fifth, choose the best technologies that can process data across processes, always on the basis of a cost/benefit analysis.

This approach allows you to create business solutions with focu on goals, avoiding redundancies both in terms of processes activities and data, which means no wasted time neither money.
Comment
And if you don't do them precisely in this order, you certainly shouldn't do it in the reverse order :)
  1. Scott Francis
  2. 2 years ago
Hi Scott, this order offers more guaranties focusing on measurable business benefits, what is really important in my opinion. The inverse order is what is more common, because many people still believe that technology can solve business problems by itself, what is not true. Just ask people who are doing the technology approach about business benefits.

At least, I think we should argue and try this order as consultants, because it's much more sustainable for both, customers and consultants.
  1. Jose Camacho
  2. 2 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Alberto Manuel Accepted Answer
Blog Writer
The datalogical world, is the “fossil” of what occurs in the organization as a result of coordination acts or business operations.

Data appears first, as a result of operation, the kind of applications after (not the other way around), despite being modelled contrary to this approach. For the objective of defining what kind of applications an organization should have, forget about the miracle an application can foster, applications should be a mirror about the kind of experience the stakeholders want to feel.

Theoretically, all the acts produced across the organization are recorded (despite this is somewhat far from the truth). Hence data (that constitutes the information architecture) is the mirror of what occurs during process execution (independently if it’s automated, normalized, ad-hoc, adaptive, etc). Today, we are headed towards the digitalization of all data as a consequence of the new norm that is, organizations are becoming digital. Hence, the data explosion phenomena, despite, there is still data on paper as also data that it is deleted.

Using that amalgamation of data, actors should have the opportunity to infer, reason, make decisions, the expression of our intellect, that is the reason of being the “Information space” – (how knowledge is diffused) that ultimately supports the very existence of the corporation.

It is curious how this theme is catching attention. I will be delivering a session at enterprise architecture Europe 2014 next week in London. Join the session called Viable a System Model meets #entarch. An expanded view of the session and in particular about what appears first, data or application is at reach here
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Bogdan Nafornita Accepted Answer
Both at the same time.

In "The Sciences of the Artificial", Herbert Simon makes an interesting analogy (and one I intend to explore further, because I find it unifies a lot of my own thinking): business processes are to business entities what genes are to an organism - sequences of instructions on how an organism should appear, behave and ultimately survive in its environment.

If processes are genes, then data is the proteins that make up (at least from an information-processing system standpoint) the business entity.

Data describes states, but processes describe movements between states. From an enterprise architecture standpoint it would be a very risky approach to take separate views on them. If one is to draw a simplified parallel with Aristotle, both processes and data make up the causa formalis, together. They only make full sense when viewed together.
Managing Founder, profluo.com
Comment
I've been using that analogy for years. But there is a problem - if your genes are wrong for the environment you find yourself in, you die. Something with the right genes takes your place. This is exactly what is happening to many big companies at the moment - they have created such rigid processes they cannot change as fast as their environment. And it is why I got involved in Gluu.biz - with ten people making decisions where there was one before companies move faster and processes adapt.
  1. Peter Johnston
  2. 2 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 7
E Scott Menter Accepted Answer
Blog Writer
Not sure about the academic side of this argument, but in practice, it's often a proliferation of lifeless, context-free data that drives you to organize processes in the first place. Think about a start-up venture: data starts to aggregate immediately (customers, price lists, financials), but rarely is there any process in place. Eventually, the company grows, and it becomes increasingly important to start organizing things such that the march of data through the business—from marketing campaign, say, through prospect discussions, through sales, and into customer service—has to be more predictable. Enter process.

Could process have come first? Sure. It's just that it never seems to.
http://www.bplogix.com/images/icon-x-medium.png Scott
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Bogdan Nafornita Accepted Answer
Your point of view is valid, but still just because a start-up doesn't have formal processes, that doesn't mean it doesn't have any processes.

That first customer, that first price list, those first reports - they must have been generated by a process, albeit a rudimentary one.
Managing Founder, profluo.com
Comment
I agree, but only if you define "process" so broadly that it ceases to have any meaning. Yes, stuff happened, and data resulted. In that sense, process comes first because something must happen for information about that thing to exist. I was speaking from a practical rather than a theoretical standpoint: the data accumulates, and becomes unwieldy, and we begin to apply process to help us get our arms around it.
  1. E Scott Menter
  2. 2 years ago
In my mind, a business process is just a sequence of activities undertaken towards a business goal.

As I said before, if someone taps a few times to save a business file into Dropbox in order to conduct his business, then he just followed a business process.

If BPM must survive as an industry, then we must learn to define the process more broadly.
  1. Bogdan Nafornita
  2. 2 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Peter Johnston Accepted Answer
The answer is neither.

Imagine you created the perfect process. Every step optimised. But it delivered product to your customer in two days when they needed one. You aren’t going to have that process for long.

Imagine you have perfect data. You can see how fast every step is, how big a lag between them, how many go one way, how many another. You could in theory build a perfect process.

But just as “No Business Plan survives first contact with the customers” (Steven Blank), neither does a process. Because if they don’t like the interface or the NEXT box isn’t clear enough, the process can be 100% slower. Or they can migrate away in droves. The data is a measurement of the old process, not the new one.

This applies just as much if it is an internal process. Your order processing process may be loved by accounts, but not suit the way your salespeople report sales. So a fight ensues between the departments. You lose. Where’s your process, then?

You’ve guessed it. My answer is the customer.

All processes involve compromise. And it is only by knowing how the customer views those trade-offs that any process can be designed at all. Will they pay £1 more if it gets there a day sooner? Will they buy into predictive ordering on a long term contract – if so at what percentage? What really annoys them – if you solve that, will they accept lower performance in other areas?

Don’t forget competitors either. Is one of them making hay out of faster delivery, or lower costs, or better packaging, or just-in-time systems linked to their customers? You can bet somebody is thinking about it. So do all the strategy thinking that most companies do for themselves, but for your competitors. Work out what they are likely to do next. And, in best Nash equilibrium fashion, what they will do when you do something a bit different – how fast can they respond? Can they trump you (perhaps with better systems, or geographical reach)?

Once you have all of those parameters you will have the answer to process v data.

But there is a major error in the question. It assumes process is singular. The idea of the guru having a one-time stab at “getting it right” is old-fashioned Lean Six Sigma thinking.

Far better to throw some Ries into the recipe. Create a minimum viable process, along with all the data links which mean it will deliver up to date data. Then ask some of your customers to play along. Pitch it to them and see what they think. Only go to pilot when you can prove to them that it is better than your old process. Rapidly build data and have another look, from a customer perspective. See how the data changes. Perhaps a happy path is obvious. Perhaps the Pareto principle – 80% of time on 20% of customers – applies. Or perhaps you can make more money for less effort if you simply change the interface to make one option look more attractive.

Once you have a process the customers like, then you can focus on improving it. Again and again and again ad infinitum - no process is ever finished. Data and process work hand in hand – but the mummy leading the way is the customer.
Dynamic Process
Oxfordshire, UK
+44 (0) 1491 874368
+44 (0) 7590 677232
#dynamic_process
peter@dynamicprocess.uk
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Pat Barry Accepted Answer
The boundaries of the process have to be defined before performance data can be decided upon and gathered, so I'd say the process has to come first.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 11
David Chassels Accepted Answer
Max is of course right must know what you are trying to achieve goals, outcomes and how with required content. Then you roll up the sleeves and start to build bearing in mind all data is sourced via people and their processes. So in that context Process come first. On the other hand the tool you use to build will inevitable be "data oriented" (ours is actually data centric";) and need a data structure. In this that context data comes first which just highlights understand "how" any "BPM" build tool actually works to build a process that creates data that delivers goals and outcomes?
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Garth Knudson Accepted Answer
Blog Writer
There are 3 main things going on in designing process-driven solutions:
- What is the objective (and associated data and documents) to complete?
- Who are the people and what are the systems that must collaborate to provide data and documents to complete the objective?
- What is the workflow that enables the people and systems to most efficiently and effectively collaborate to complete the objective?

Based on these three questions, knowing what to collect is first, who has it is second, and the workflow to enable it is third.
Comment
the objective (outputs) are only part of the picture though. you don't have the inputs. and the inputs will depend on the workflow and the people involved (and what they have access to). pragmatically you can't access the NSA's database on all of our data ;) so you have to figure out where each bit is coming from or who produces it, and when. and your process will uncover holes in the data model 
  1. Scott Francis
  2. 2 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 13
Because an enterprise is a system (at least in my EntArch), the system comes first and all enterprise artefacts are equally important (although not all of them were mentioned in this discussion). Instead of asking which artefact is more important, I would ask - is an enterprise a system of data? goals? content? functions? services? capabilities? events? PKIs?

Classic EntArch does a great job in describing the full nomenclature of enterprise architects or “enterprise genotype”. Unfortunately, just knowing “enterprise genotype” is not enough to derive the “enterprise phenotype” (a set of observable characteristics such as performance). To bridge “enterprise genotype” and “enterprise phenotype”, it is necessary 1) to model (or make explicit) relationships between various artefacts and 2) make these relationships executable (also to be able to simulate them). Fortunately, artefact “process” is one of the ways to have such explicit and executable models.

Thanks,
AS
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 14
Ben Farrell Accepted Answer
I love seeing so much healthy debate on this topic. That's why we chose to put it to our panel at Appian World 2014. The two quotes that kicked off this discussion came from an Appian partner and an Appian customer. We had two other customers arguing the "process first" side. But in reality, there is no single answer. We're BPM people; we love process models and we understand their value. But if your view of how work gets done can only start with a process - all the time, every time - you are missing out on how new work patterns are emerging. In some work styles, like case-oriented work, decisions and actions must be "launch-able" from data state changes, invoking social tasking and structured or loose processes as needed. We find that many of our customers who are realizing the "intelligent process" idea (or whatever you want to call it), start their thinking from a data perspective. But certainly not all of them. The divergent viewpoints we had represented on our conference stage seems to be fairly reflective of the real world (and the discussion happening here at BPM.com).
Comment
I also agree whole-heartedly with Max's comment that both approaches must be subservient to the business goal they are proposing to address. Thinking from that perspective can help clarify what mix of data issue/process issue you have on your hands.
  1. Ben Farrell
  2. 2 years ago
Well, I also agree that the business goals come first, but responding like this is actually cheating :-) This is reframing the question asked in order to outsmart other responses.

If the question is "chicken or egg", if you want to outsmart the two possible answers, you just answer something like "macromolecules" or "metabolism" as prerequisites to either the chicken or the egg.
  1. Bogdan Nafornita
  2. 2 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 15
Scott Francis Accepted Answer
Blog Writer
If data are inputs, outputs, and side-effects of the process, then your process definition and context will drive your data requirements for the process. Try driving it the other way around :) You end up with a data maintenance app - which might have been what you really wanted, rather than a process.

The answers re: "goals first, objectives, etc" are all valid - but isn't that part of how you define the process (it is for me)? They aren't "data" as in things that get put into the schema and passed along as process variables :) So to me, those elements are part of "process first". And unfortunately that simplification makes it sound like you can't start thinking about data til you're done with process, but obviously that's not the case - it is incremental and, in our method, iterative. but data definitions stay flexible throughout process definition and development.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 16
John Morris Accepted Answer
It's not a surprise that champions of process technology take a process-centred view. And that world-weary "been there done that" view is not wrong. Especially when we accept that we naturally should start with business goals and objectives and then get on with the work of business -- with that work defined by business process.

But this naturalistic view of process is not really the meaning of the data versus process debate. Fortunately no one mentioned NoSQL here; nevertheless a tendency to diminish the importance of a strong data foundation is part of today's world. Against that view, I propose that a strong data foundation is a sine qua non of any software project (I don't think anyone here would disagree with this).

So how in layperson's terms can we express the importance of data? We could say that a strong data foundation is the formal, machine-friendly expression of human understanding of the subjects and language of business. And like any language, when you know language you can express anything.

One can think of process as the narrative or story of the work of business. And this "story of the work of business" is truly where value is created. Hopefully your story is oriented to supporting organizational objectives!

But process-as-story is just exactly that, a language construct built from the fundamental semantic building blocks of organizational work, which is your data model. So, from this perspective, there is no chicken or egg; data is prior in the same way that any language is prior to story.

Story telling is the most powerful of human interactions. For this reason, the technology of story telling or process is easy to support. And in our debate here we have lots of compelling stories.

On the other hand, the freedom offered by rational technology is not as naturally human. We've seen the consequences of casual information technology before the arrival of relational database. Before relational theory there were network and hierarchical data structures, notoriously inflexible and difficult to work with. The paradox of starting with data is that you obtain the maximum degrees of freedom to define your process or story as you like.

That said, of course process and data will always be in tension (I'm tempted to say they have a "dialectical" relationship). But a case can be made both formally and culturally that a little more emphasis on good data models would go a long way to solving some of today's technology-related challenges.
Comment
I like the language / story analogy.

So, how does one go about designing a language without creating, at the same time, the nouns + their attributes (data) and the verbs (processes)?
  1. Bogdan Nafornita
  2. 2 years ago
The question isn't "whether" to have good data models or not... the question is "when". Before you know the story / narrative or after?
  1. Scott Francis
  2. 2 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 17
  • Page :
  • 1


There are no replies made for this post yet.
However, you are not allowed to reply to this post.