One missing element to understand my message is the pragmatics. Therefore the intention is built here, based on what I experience too regularly.
In process descriptions*:
- The focus lies too much on activities: the activities are measured in time and costs, promised for one of the 2, sometimes including quality requirements. There is the psychological aspect one has to perform activities as a reason of being, the more activities you master, the more resources you can bargain for and the more influential you become. At least for the processes producing information or knowledge, which represent a big part of the economy*, I would like to shift the attention to the transformation function of processes.
- Data gets no or insufficient attention in the modelling exercises. While this should be the primary concern in processes generating information or knowledge.
- There is a misconception in what data is. When a document is input to a scanning activity, whereby a file is produced, there is a transformation of data carriers. No data is transformed. The same when a document serves as input for a split operation (document x is split into documents a, b and c): there is no data involved. For the concerned parties, these information carriers represent well known and shared information; the separate documents even have different lifecycles based on regulations. The regulations themselves being tight to particular data carriers. All this makes we are facing archaic processes and procedures which are not questioned, thus updated. And we continue to describe and process without data transformation. And yes: we continue with plenty of activities...
- What I also see is that each implemented process owns its data model and manages its own business rules. Without master data management, which should include rules, this is the perfect recipe for chaos and arbitrariness.
- There is no opportunity to implement data based processes which means a lot of interoperability possibilities are left unattended.
Data are for me, in the scope of this message, facts **. Processes produce data***. Data is transformed into information through data models and business rules. There are different applications which implement these. The traditional ones with ERM conceptual data models and rule engines. The alternative is RDF, RDFS, SKOS and OWL with SWRL or RIF rule descriptions and executions. Of course the latter gets my preference, the reasons for that are covered through my website (http://fadyart.com). When the traditional techniques are used the representation can be ERM or class diagrams, when the preferred alternative is used, the representation is through graphs. The readers here will not have to be explained what the rdf (s) and owl graphs are I believe.
To handle information, there is no particular knowledge of the domain requested, the knowledge of the data and the rules is sufficient.
To transform this information into knowledge one needs to know about the covered domain. Sharing knowledge about a domain can be done through the build of a knowledge model, like an OWL ontology. Building the knowledge model or, without model, sharing otherwise expertise and the interpretation of information in a domain requires specialized knowledge but put in a larger scope.
As for the category of the physical services there is no single category of resources other than the skills and capabilities which are transformed. This is particular to physical services: a wide diversity of inputs with a constant of specialized skills and capabilities. It is true that also the other sectors need capabilities and skills, also agricultural products can be input to the physical service category,… most economic players understand the distinction. I had expected more questions from the fact I divided the service industry into 3 distinct ones but that seems to be accepted broadly.
* also management and support processes are affected
** I know there could be a distinction made between facts and data, but for the purpose of my message there is no use of it. Anyone interested in using the distinction to sustain my message is welcome however.
*** in accordance with standard notations as BPMN and EPC. Also the execution engines do. But I agree there are cases where information is produced.