Skip to Content

Can you analyze a business process map from an Etch-a-Sketch drawing?

I wanted to share my thoughts & some information about a newly introduced product in the Japanese market, and even more recently, the North American market. Developed by Fujitsu’s Interstage group, this product/service is called Automated Process Discovery, and I think it has the potential to make a significant impact on how BPM is used in organizations and how it is used by practitioners, whose aim it is to help people understand & improve their IT architecture in the context of their business processes. But before going on, I would like to jump start your attention by putting forth a question: Would this product (or products like this) assist you as a BPXer, and to what extent would it enhance & expedite the manual process analysis? 


What is it & how does it work?


So in a nutshell, the automated process discovery engine enables companies to extract information from their present enterprise applications, which are saved through log files & databases, in order to see a complete picture of their business processes (to whatever comprehensive or over-simplified degree desired). In other words, if you want to understand & see a visual representation of what business processes & workflow are happening within your organization, the automated process discovery will generate a report showing a pictorial representation of any and all events, as well as the exceptions. You likely have heard the common ‘hairball’ analogy associated to a dense spaghetti-like congestion of process paths…well comparatively, the automated process discovery’s data output of an organization’s overall workflow process is about as hairy as it gets! You can see what I mean in the image below, which shows an actual report from Fujitsu’s process engine, referenced from Paul Harmon’s blog/article about the technology.

 Paul Harmon's blog 















These path analyses can also be refined & sifted according to different criteria such as variations, recurrences, frequency, feedback looping, and particular transfers that may indicate potential bottlenecks. Better yet, it doesn’t interfere with existing systems or users throughout the process, since it is external & doesn’t require an adapter to be running on the ERP/legacy system platform to do the process mining (which I believe is the case for a similar tool from ARIS called Process Performance Manager (PPM)). For a series of different process analysis results, check out Sandy Kemsley’s flickr photostream on automated process discovery. 


Who can benefit & how?


There are many different groups/roles who could benefit from this service/product, namely:

  • the business analysts (who spend arduous hours sniffing out clues, gathering interviews & documenting everything that happens in an organization’s workflow processes).
  • the quality managers (where, much to their satisfaction, particular case study trends could seemingly pop-out of a data visualization, to which they can make decisions & improvements accordingly).
  • the stakeholders (we’re talking minimal investments in time and $$$ when considering what would normally take hours-on-end for high-priced consultants to weed out workflow issues with interviews & sample transactions selected, to some extent, at random).
  • the security specialists (whereby a tool to this level of sophistication could potentially expose unwanted legal issues, fraud, and breakdowns in compliance that may be concealed beneath the workflow’s surface).
  • the operational/administrative personnel (since automated process discovery’s ability to optimize, identify, predict, & locate specific data based on different process criteria has virtually no impact to customers or the general day-to-day operation of the company, as does a standard process mining exercise).

And in the spirit of what BPM strives to bring to our present-day industries & markets, one of the greatest virtues that automated process discovery provides to the BPM world is a means to facilitate the interactions between business managers & IT, such that business managers can be involved from the very beginning, being better-equipped to inspect process data laid out in front of them & to understanding how everything fits together, based on the visual representation produced by the actual event log files of their business processes. Furthermore, when applying different parameters using this engine, these same business managers can make well-informed & important decisions relevant to the processes’ data findings as their organization’s environment evolves. 

How is it applicable to BPXers?


 Most of us in the BPX community understand how complex business process mapping can be, and despite whatever advancements have been made to the requirement/information gathering process, it is still not altogether a straightforward task to get to the bottom of any given organization’s business processes as they relate to its IT architecture. Moreover, this very labor-intensive mapping process oftentimes only offers a glimpse (at best) into the yarn-like maze of IT & business paths and may even lack the accuracy necessary, which an automated devise such as process discovery can deliver. With simulated execution, human error is not really a factor because this tool sets the parameters to highlight not only the key workflow paths, but also the exceptions, as well as infrequent & indirect paths.  

By no means is this blog meant to endorse the Fujitsu product – I was actually led to automated process discovery by a well-informed BPXer in her own right (thanks Marilyn!) and have gotten quite interested in this innovative tool now that I know about it. 

So to get to the point as to why members of our community might care about such an advancement, I would like to draw your attention to a statement which resonated with me, written by Sandy Kemsley in her recent article about the subject. She writes that it’s “sort of like using simulation with real data. This isn’t an automated tool that takes data in one end and spits out the answers at the other; it’s meant to drive discussion and analysis, not replace it.” That’s at the heart of the business requirement gathering process in my view – the ability to generate a productive interaction between the business experts & IT experts (or somewhere inbetween). And wouldn’t that be a good space for the Enterprise Architect to fill (that inbetween part)?? 

So now that you know a bit more about Fujitsu’s automated process discovery, I return to my original question: Would this product (or products like this) assist you as a BPXer, and to what extent would it enhance & expedite the manual process analysis?


Referenced Sources:

You must be Logged on to comment or reply to a post.
  • I already know some details about the PPM tool you mention in your blog. I think your tool can help to make existing parts of processes – the parts that are IT supported – more transparent.

    But let me ask you what the benefits are?

    If you want to use the diagrams to derive information about the processing time, you need to have the possibility to add manual parts of the process. This is also a prerequisite to calculate the process cost (I would assume the process cost often mainly depend on payroll cost of the involved employees).

    • Thanks for giving your input Thilo.

      In response to your comment about needing to factor in the manual parts of the process, I am of the view that process discovery is intended to <<complement>> the manual parts. I agree that it has this limitation in terms of measuring process time/costs of manual processes — however, it is apparent to me that this would not be one of the primary functions of this tool.

      Because process discovery is not taking into account the processing time of manual steps in an overall process, the cost of /time for manual parts of the process will have to be determined & separately added to the data derived from this process engine. But still, the real capability of this tool lies in its <<automated>> feature of capturing the steps of a process, since there are so many details behind the automated world which end-users are not aware of, and that the tool can bring to the surface.

      Just to give an example, a standard sales order process in an SAP ERP system checks for pre-defined criteria using various parameters such as ‘ship to’…‘sold to’…‘valid customer information’. And one of the common KPIs in the consumer goods industry is order processing time, which can be negatively impacted by the previously mentioned criteria. So if a tool like automated process discovery (or any other tool with similiar capabilities) can help to highlight its impact on KPIs, I believe it is beneficial.

      This, in turn, can also point the spotlight on certain trends that decisions-makers can utilize to improve their business process in the context of their KPIs.

      • Hallo Ranjan,

        you are right, this kind of tools provide some information as a starting point to detect weaknesses and improvement potentials. But it woud be even more beneficial if the process detected by these tools could be acomplished with further information. Otherwise it is mainly limited to cycle times from one status/event to another. The parts inbetween remain a black-box.

        • Yes I agree Thilo – I think that would be the ultimate objective, to <<combine>> the analysis of automation with a method to capture the manual processes.

          This subject definitely is thought-provoking, to which I would like to add 2 more cents worth…

          Based on my experience with different clients, I would propose that there is always going to be some part of the process that is manual, no matter how automated this world gets.

          But I’m inclined to consider whether it would be worthwhile to automate each and every step of the overall process, or if we still <<need>> the manual parts???

          In any case – the manual steps within a process seem to not be going away anytime in the near future, and I think it would be very difficult to come up with a tool that automatically captures information about those manual steps (without involving <<some>> element of dialog between users, analysts, etc.)

          Also, I would be interested to know if anyone has information/statistics (however specific or generic) that reflects the ratio of manual to automated parts of the processes within any given organization. Quantifying how much is manual, how much is automated — that would be good to know…

  • I’d like to add some points to the question of process discovery of partly automated vs. fully automated processes.

    Most customers I met are looking for process analytics at process runtime only by focusing on performance measurement. That is probably, because such initiatives are driven not by IT (“what is technically possible to measure/discover”) but by business (“where is our biggest pain to be solved”). The “process pattern behind each indicator”, which PPM uniquely delivers by its automated process discovery, is often considered as a nice-to-have at the beginning of such initiatives.

    The automated process discovery is not in focus, because there is a common mindset that “process models” have their place at design time only. Later in the project the process discovery is rather an eye catcher for the business manager. He cannot believe that a process standard like A-B-C cannot be executed always that way. Sometimes an instance A-C leaves out activity B (e.g. an order with an invoice but no delivery), or the sequence was wrong A-C-B (the invoice sent out before the delivery). Of course, the operational departments (actually executing the processes) know very well such routine (“we do that all the time”).

    But such significant insight for a process- and hence a business improvement comes not for free. Just squeezing each and every bit of IT’s runtime data without asking the business which process and data they really need, is not a promising way to go.

    It is required to define an end-to-end process with measurement points on its way through the involved departments and IT applications to measure the right things (organizational breaks, application interfaces etc.) and start and end at the right spot (“who requests what and where is it fulfilled”).

    At IDS Scheer we call that Process Intelligence. Because unlike BI tools gathering the whole company’s data and filling up data warehouses with vast amount of data but without much relations, we focus on one or more end-to-end processes from a business need to its fulfillment or failure.

    Also it is interesting, that Fujitsu EST is reselling ARIS PPM for some time under the brand “PPM for Interstage BPM”. Other vendors are reselling PPM too: SAP (“SAP Process Performance Management by IDS Scheer”), TIBCO (“iProcessAnalytics”) and Ultimus (“Ultimus Enterprise Performance Manager”). So neither ERP nor BPMS can offer such a process-driven solution yet.

    • Thanks for your detailed comment Rune (could even be considered as a blog on its own!)

      Your statement: “Just squeezing each and every bit of IT’s runtime data without asking the business which process and data they really need, is not a promising way to go.”

      My response: Just to clarify – I guess we are still far from being able to document best practices for usage of automated process dicovery tool, but this activity of atuomated process discovery for performance measurement doesn’t need to be an initiative ‘driven by IT’ (nor should it be).

      On the contrary, it should be a <<business>>-driven initiative, which is supported by IT through tools such as these. This point is percisely what I had aimed to convey – that it can be most effective for business managers to be able to watch certain characterisitics of process operations within their organization & to form their decisions around those observations. Furthermore, automated tools like these can <<and should>> provide an effective means for fueling discussions between IT and business when analyzing what is happening on an automated level (not just spitting out ‘the answers’).