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

If a process isn't documented, does it exist?

Vote 0 Votes
A question raised by Craig Reid, undocumented processes exist in a grey area of a business.  Is this a good or a bad thing?

16 Replies

| Add a Reply
  • Think this is the same question we asked and answered in August about Dark Processes....?

    My answer was: Instead of reducing these processes we should expose and understand why they exist in the first place. If they exist it's because our so called 'best practice' is anything but and removing them erodes business success. Perhaps Dark Processes are the next best practice we can find, and rebels are responsible for their existence.


  • Neither.

    These days the process is all about interaction and it cannot anymore be analyzed naively taking into consideration the dispersion, complexity and interdependence of relationships, something that can also be applied on IT requirements elicitation or IT system operation , which allows to understand communities interaction in order to support emerging and unique processes under a techno-social systems approach.

    This means that most of processes are not documented, but his is not a problem.

    Enterprises are (finally) becoming self-organizing systems alike , but there are important patterns that emerge from the nature of the coordination acts that can be identified. Despite there are random factors and the type of patterns presented in most of scientific papers are based on graph theory and tend to be very simple compared with the reality (and hence maybe this is one of the reasons they are not taken seriously) it is the only way, as an abstraction, to understand agent behaviour. Pattern recognition is critical to align process type (from structured to unstructured), knowledge domain (simple to chaotic) and network type (central to loosely coupled). In order words, to infer trends and help humans to interact better regarding the role they play in the process ecosystem. Having said that, I would like to invoke Stafford Beer’s on models: “in general we use models in order to learn something about the thing modelled (unless they are just for fun)”

    Solution to discover undocumented processes? Combining Process Mining with Social / IT network Analysis.

    Some more info can be found here: http://ultrabpm.wordpress.com/2013/03/25/social-network-analysis-part-two/

  • The process exists regardless of the level of documentation and/or controls placed upon it. Its very similar to the though raised by John Zachman about an organization's "enterprise architecture" (EA): Whether its documented or not, the architecture is present within the organization. Sears, Roebuck, & Co. had processes (and an EA) when it was established in the latest 1800s.

    Is it important to have these processes documented? Yes, but more so with those processes that are directly linked to generating value for the organization and its customers/beneficiaries.

  • Craig is confusing two distinct domains: business rules and business process.

    The process that is undocumented - and in my opinion it shouldn't be documented - is a child of the process "Engage employees", perhaps "Offer fresh fruit." This one has at least three sub processes: Accept fruit delivery, set up fruit display, take down fruit display.

    There are rules in place for each of these. There's a business rule attached to the "offer fresh fruit" process. This rule defines the parameters by which individuals may take the fruit.

    But who would want to work for a place where people argued over basket fruit?

  • If my trip isn't highlighted on the road map it doesn't exist? Of course it exists. The trip is real life, a map is just 'a model' of it.

    So a process exists if it is not documented.

    If work is done to deliver products, services or to solve problems the process exists.

    Be aware that not every process the same as 'doing a collection of tasks in a predefined order'. A process is 'the thing' that helps companies to do what they promise.

    So execution and knowing what is happening (in real life) is more important than any process map. Making clear the result to employees and implement the right level of steering; that is what process management about.

    Customers don't care about documented processes, they care about executed processes.

    And insight in a process is not the same as having modeled your process.

  • It is both a philosophical and a practical question. The answer is simple: Processes DO NOT EXIST whether you document them or not. Also an architecture is purely human invention. What you document is an illusion or at best a hypothetical ideal path from a current state to a desired state of affairs. It has little to do with reality and just because you put it into a flowchart diagram it doesn't become real. Paper is patient ...

    Processes are an artificial human invention that make sense in areas where strict adherence to a sequence of physical actions within strict tolerances leads to a desirable physical outcome = manufacturing!

    In all other areas of production and service, for example agriculture, processes do not exist. People act and react to states and events accoriding to their best knowledge that is created by experience and not theory. Processes are one way to describe business interactions and as long as they remain a high level mindmap they have a place in BPM theory. As soon as someone falls into the illusion that human interaction can be controlled by means of pre-defined processes, things go badly in the wrong direction.

    The only way to define processes is to look at them through the lens of business strategy. This means to take a goal oriented view and explicitly define objectives, outcomes, goals, handovers and operational targets. As it happens neither BPM theory (as there is no proof that the methodology works) nor BPMS (software) works this way. They both follow the flow-diagram fallacy.

    Let me also respond to Alberto's perspective:
    He properly understands that businesses can't be controlled by flow-diagrams. Social interaction is what drives businesses but that does not turn them into a replacement for a goal-oriented process perspective. I have posted in this before here so I won't repeat everything and I apologize for the duplication.

    Process mining or Social Network Analysis needs people to perform processes in an environment that allows both mining and identification of goal oriented activity. That simply does not happen. There is a well-known data collection and to the time stamp accuracy problem. But that is not the only issue.

    Social interaction thrives on the ability to stream information to a large number of people. That is utterly wrong for most business processes. Attaching process info to a Social message as a hyperlink seems cool but is not really Social because the receiver would need to be authenticated as performer. What process management can learn from Social is the subscription mode that enables well-known performers to be notified of certain events even if that is not defined inside a process or case.

    BPM flow-diagrams restrict as much as Social democratizes. Business processes are not about democracy but about doing business, which means purposeful collaboration towards process goals and (operational) targets, delivering handovers and achieving customer outcomes. Social lets people interact without any purpose and BPM enforces an analyzed TO-BE process. There is a huge gap in between.

    That is the gap that can be filled with adaptive process definitions (as in ACM) that start with defining why to do a process and what it delivers explicitly! The one thing Social won't do is to replace goal-oriented work. It is however a natural component of an ACM case-oriented process definition as long as it supports clearly defined goals.

    Finally, with neither documented BPM processes nor with Social there is no embedded learning and improvement for the organization. Meaning there is no Adaptiveness (in the evolutionary sense) but either rigid or total ad-hoc interaction. One can use complex social network analysis to dig out some repeatable process fragments AND THEN? You document them and put them into a BPM system?

    So what generates value? Yes, in manufacturing it is the knowledge of the process but it still has to be implemented and monitored by able individuals, otherwise the quality controls of the Toyota Production System would be unnecessary. For non-manufacturing human interaction, we can't put a TPS into place as much as that seems desirable to some. Humans work in social networks but they need well-defined goals, authority and means (budgets) to succeed. The last thing they need is rigidly defined flows and completely unsupported social interaction is worse than email.

    So pardon my conviction that neither BPM nor Social will do the trick. It will have to be something like a 'System of Engagement' that empowers its users and guides them to business goals. I really do not care if it is called ACM or something else.

  • If you can’t document the process, there really isn’t one. Even if it were informal, you could say – ‘we do it this way most often.’ Without documentation, who performs tasks within the process? Without documentation, what tasks are being performed? And, ‘who is to say what is right or wrong?’ is an understatement.

    This brings up an interesting thought – If a process is not important enough to document, why are we even talking about it?

    My conclusion – if a process is not functioning properly, there will be some costs associated with it. If those costs are high enough, the process will get documented. If only to find out why there is a problem.

  • Of course it exists. If not someone is getting a salary for supposedly doing nothing :)

    In all seriousness, we document processes that produce business value to customers. However, do you document when an admin staff makes a copy of reports that are unrelated to producing a business object? We must use a certain level of common sense to filter certain tasks and focus on the core business.

    With regards to Craig's post, it really depends on the context of the process and perceived business object at the end. Process documentation/modeling requires responsibility and this is a new zone for many and will take a lot convincing to put their name on the model and say they "own" it.

  • A process that is undocumented exists only in the minds of its actors. Funny thing is: this is true as well of a process that is documented. Humans being the unpredictable creatures they are, even the most meticulously documented process is unlikely to happen the same way twice.

    The only process that truly "exists", in the sense that it is reliably reproduced on a recurring basis according to its design, is one that is automated.

  • Get an invitation to talk to knowledge workers in any department of a large organization. Ask them how long it takes for a new employee to get up to speed and become productive. Find out why it takes so much longer than you would have guessed.

    From my experience doing this, I've observed that there is a huge amount of 'process' that is passed on by word of mouth, based on experience of the departmental elders. Before the process tools (either methodological or software) were truly invented, this social approach to process management and training thrived, and still does to this day.

    Employee turnover, regulation and occasionally 'perceived' ROI lead organizations to document processes to try and improve them. But those hidden processes communicated through folklore and word of mouth will always remain and grow to fill gaps, which is why social tools and mindsets are so important for modern organizations.

  • If a tree falls in the forest when no one is around, does it make any sound?

  • In smaller organizations, startups or small departments processes are often never documented, people just know what to do. Because the organizational is so small you can generally get by, training is by word of mouth or, by example.

    In large organizations processes, tend to start out being documented, but over time they change and this is not always documented. In addition workarounds develop to address problems that arise as the business matures and new ways of working are introduced to cater for new opportunities.

    All this means is that over time business processes or discrete activities are maintained in peoples heads.

    The challenge comes when you want to identify issues and implement change, then you need to identify and visualize what is happening. Documenting processes, by what ever means, is a simple way of identifying the challenges.

    So in short invisible and undocumented processes do exist and are a normal course of doing business.

  • To answer your question, yes it does exist. Everything we do in life has a process associated with it. From when you wake up in the morning and go through your morning habits till you go to sleep and follow your night routine. These are all examples of processes that exist but are undocumented. The only difference with a documented process and an undocumented process is that the documented process is controlled, to a certain degree!!!

    Now I go back to my Lean Six Sigma training , the final stage of DMAIC is control, and one control method is to document the process to insure standardization and all are following the same process.

    This does not mean the process is a negative process if its not documented. We see many “Mom and Pop shops” small SME’s that have no documented procedures or Manual, and they do not need it. They have the process ingrained in their heads and they do not look to duplicate their work. now once they decide to open other shops they should look to document processes to insure same output with the same quality "control".

  • Let's keep this simple reflecting the basics. Applications are simply implementations or expressions of process. Process is a series of task activities, human and system, aligned to business strategy and specific outcomes.
    Good supporting software will automatically document both what the process is and the run time activity. So we are talking about activity happening outside the formally digitised environment?
    Well of course such activity does take place and may be recognised but not documented in the same detail. What will be documented in the formal process is who did what when and if this creates new information someone can be held responsible and questioned how new information was created which may involve informal undocumented activity? This is empowering people which is good but only if there is transparent measurement and accountability.

  • The not documented processes often are the most important process in a organization. Some organizations, particulary in italy have all process documented and stored in a drawer but users follow their process or their procedure because during the time they refined, like a lifecycle, the work in order to do it faster and safetly their work.
    the key is to take from the drawer all documented processes and refine it with the help of users and ask to them how is possible to increase the performance and productivity using a mix between their not documented processes and official documented processes and, the last but not the least, ask them how the systems must change to do this.
    another issue is when consultant company start to do a Business process reenginering project... why does they don't speak whit users and talk only with organization office, demand office or middle-management people? this type of peaple know only the processes put in the drawer
    maybe I'm too much negative? Or I did too many BPM projects and I have suffered for this?

Add a Reply

Recently Commented On

Monthly Archives