BPM.com
  1. Peter Schooff
  2. BPM Discussions
  3. Tuesday, November 17 2015, 09:49 AM
  4.  Subscribe via email

An issue raised by [url="http://www.bplogix.com/"]E. Scott Menter[/url] in [url="http://bpm.com/bpm-today/in-the-forum/do-you-see-process-mining-playing-a-bigger-role-in-bpm-in-the-future"]this discussion[/url] on process mining where he writes: "Everybody is way too focused in general on the 'as-is' or current state of a process. Sure, there is some information that's worth knowing—but in general, I find the obsession with the precise documentation of a process you're about to replace a little odd." What do you think?
Patrick Lujan Accepted Answer
Blog Writer

Yes. At a high level it may be acknowledged that the process is "broken" and the focus should just be on modeling the to-be right out of the gate. The reality is, however, the as-is is and can be instrumental to understanding the "who, what and where" as to WHY it's broken. This is process discovery and though I believe that the heavier lifting and effort should be done in the "to-be," the "as-is" is oftentimes necessary to UNDERSTAND the existing processes and what's wrong with them because the organization, client themselves may 'think' it's actually one thing that's the problem and, after discovery, it turns out to be something else altogether.


Don't discount the exercise but, "yes," don't dwell on the "documenting to precision" ad nauseum, ad infinitum part. Just get to the point where you understand, then move on.


Just my tuppence, but I do spend a lot of time doing this and see the above a LOT.


 
Comment
Right. I think the thing is that we are all still doing plenty of "process improvement", which of course implies you have to be pretty familiar with the thing you're improving. But we just have to make sure the tail isn't wagging the dog. If my goal is to identify opportunities to fundamentally change the way I do business, I want to think about that without contaminating my thoughts with "this is how we've always done it."
  1. E Scott Menter
  2. 1 year ago
Scott,

Agreed, and that's the holy grail for all of us - true "transformation," but unfortunately organizational boundaries, politics and money usually have that off the table coming in. If there is (and I've had a couple; they were glorious) a true interest from senior management in transforming, innovating, disrupting and all that good jazz with an overall goal in mind and they're willing to see that through it... is... awesome.

In the interim though, for a prole like myself, it's mostly about looking at what they do now, how they do it, why they do it that way and doing what I can to make it better - people, process and technology all. As much as they'll let me anyway.
  1. Patrick Lujan
  2. 1 year ago
Sure. But the point is that process improvement isn't always the goal. In fact, more and more, we're using BPM to help leverage true business transformation. Fixation on the as-is tends to restrain the imagination, limiting our ability to achieve the what-could-be.
  1. E Scott Menter
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Emiel Kelly Accepted Answer

It's not bad to look at how your current process process is performing, but that is not the same as modeling the as-is process. It should be tied more to daily execution where process performance is shown live and people are trained to execute upon it.

 

Turning has-been models into might be models is good for my consultancy fees, but I doubt more and more the value of it.
Common Sensei at Procesje.nl
Comment
+1 for "I don't want to get endorsed on Linkedin for 'helping organizations to get efficient in useless processes'".
  1. E Scott Menter
  2. 1 year ago
Sounds fun to do, Patrick. When I was young and naive, I sometimes sat in at #Houseoflies sessions just assisting using the tools and model processes for them into extremely detail.

I felt uncomfortable (I had to pay the bills). at that time to ask them if it is really useful what they were doing, because I saw the people in the room playing patience, checking their mail and other inappropriate web sites. btw I never read the reports with 'advise for process improvement' that came out of those sessions.

So now I always apply what I call 'Discover' and 'Prioritize' (are you really sure this is a real process and it needs attention?) because I don't want to get endorsed on Linkedin for 'helping organizations to get efficient in useless processes'

Although...for 200 € an hour, I might consider it.
  1. Emiel Kelly
  2. 1 year ago
@Emiel, know what the funny part on this discussion is? I'm conducting twice a week 'Lunch 'n Learns' with an American Fortune 500 on this right now. Sure we'll get into BPMN and IBM Case Manager implementation and "guardrails" later as we dive down, but my up-front statement in the first session was that I wanted them all to be really good process analysts when we're through.

I sure know the #HouseOfLies crowd ain't gonna do it, much less do it right.

:D
  1. Patrick Lujan
  2. 1 year ago
In addition: Mapping the AS-IS (in front of a live audience :-)) sometimes does a wonderful job causing awww effects and Ah-Ha Erlebnis... People who are so tied to functional silo thinking sometimes need AS-IS graphical "in the face" :-).
  1. Walter Bril
  2. 1 year ago
Agree. The goal is to improve the right process and be very clear on what the process is.
  1. Emiel Kelly
  2. 1 year ago
It's about them not knowing what they don't know and helping them with that. The process discovery segue to as-is helps and garners buy-in, advocacy, consensus if done right and not dwelt upon too much, spend too much time on it.

"For thinking about new processes; ok."
  1. Patrick Lujan
  2. 1 year ago
I absolutely like Alec's work (I even went to dinner with him once) . Especially his vision on process discovery.

But modeling processes in detail to understand how it is going now....not sure if it lives op to it's promises. For thinking about new processes; ok.

But I always try to create a way to bring improvement as close as possible to execution.

I don't say that is easy, though..
  1. Emiel Kelly
  2. 1 year ago
Here is a place where you and I would maybe disagree.

Read this, then circle back 'round to me - http://amzn.to/1NZl6Jc
  1. Patrick Lujan
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Tim Bryce Accepted Answer

Yes, if for no other reason than to capture the data used in the process.





Often times, there is nothing wrong with a business process that a little tweeking couldn't fix (as opposed to starting from scratch).
References
  1. http://timbryce.com/
  2. http://www.modernanalyst.com/Resources/Articles/tabid/115/ID/458/Current-Systems-Analysis.aspx
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Juan J Moreno Accepted Answer

In my opinion, this question has a lot to do with change management. Ideally, you should just know how the processes run now (the “as is”), and then model and automate improving it (the “as it should be”). This is great in some organizations, mainly in the private sector.


But, this is not the case when the organization is very conservative. For example, in my experience working with Latam government agencies, it is a very bad idea to automate a process and at the same time change it. Too much change for people who have done the same thing, the same way, for 20 or 30 years. In these cases, it is much better to make one change at a time. First automate the process “as is”, introducing tools and automation. Then let the process run for a year, get objective measures (KPIs) and then improve what really has to be improved, but with the support of your users.
Comment
Aauuuggggh.... I hate "lift and shift" on to new technology. Of course people are attached to their processes.
  1. Patrick Lujan
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Walter Bril Accepted Answer

[i]"[/i]
[i]Those who cannot remember the past are condemned to repeat it."[/i]
according Spanish writer and philosopher George Santayana...


And to a certain degree I think this makes some sense. I want to learn why certain things worked better or worse. And I definitely do not want to make the same mistakes over and over again. Now... with faster evolving markets, technology etc. this becomes somewhat of a challenge. So therefore I believe in a hybrid apporach. You wouldn't want to capture every single process down to an infinite level of detail.
[i]But you do want a proper and relevant context! [/i]
In 2013 I wrote a small [url="http://www.theprocessbalance.com/news/map-those-as-is-processes-yet-again-or-save-time-with-process-mining/"]blog[/url] about this which addresses specifically the concerns I have with applying process mining as a means to capture the AS-IS.


Summarized: I think you need to understand the context and big picture (say 1-3 levels max). From there you drilldown (e.g. using process mining)
[i]only on a need-to-know base[/i]
.


 
Comment
Oh, and one more thought: with due respect to Santayana, I'd argue instead that those who can't leave the past behind will abide there forever. :)
  1. E Scott Menter
  2. 1 year ago
Yeah, I think this is largely what I was getting at. On the one hand, you don't want to be "condemned to repeat" the past.. On the other hand, you also don't want to always be fighting the last battle.

The trick is to take the lessons you've learned and move forward, rather than spending too much effort obsessing over the past.
  1. E Scott Menter
  2. 1 year ago
Completely agree. Another thing that popped up yesterday is related to an article Roger Burlton recently posted:

https://www.linkedin.com/pulse/tackling-risk-management-process-improvement-same-time-roger-burlton?trk=hp-feed-article-title-share

In such cases it definitely helps IMO to have a single source of truth kind of repository of the AS-IS.
  1. Walter Bril
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Jim Sinur Accepted Answer
Blog Writer

It depends on the goal of the new process or digital transformation effort.


1.) If you want to move to a significantly new business model with significantly different set of processes, the "As Is" is used to make sure something really important in the old process(s) are not left out as a flow, step or policy. It is usually done last for verification.


2.) If you are looking to improve a process or design one with similar outcomes, then the "As Is" carries more importance and is usually done first


3.) If you are doing incremental trnasformation, the "As Is" is essential to create the necessary transofrmation steps.


I don't see where an "As Is" doesnt show any value. It's question as if the "As Is" has a core role or advisory role.


 
References
  1. http://jimsinur.blogspot.com/2015/03/digital-transformation-just-blow-up.html
  2. http://jimsinur.blogspot.com/2013/07/incremental-transformation-is-here-today.html
  3. http://jimsinur.blogspot.com/2015/04/can-you-order-transformations-over-easy.html
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Garth Knudson Accepted Answer
Blog Writer

It's always a good exercise to analyze/understand the "as-is" process to lay a clear foundation for designing the "to-be" solution. Rather than doing it with a heavy emphasis on modelling, approach it from a Lean consulting perspective.

 

After identifying and prioritizing projects, create a SIPOC map for the selected process. SIPOC stands for Suppliers (e.g., Fund Member), Inputs (e.g., New Business Application, Claim), Process (e.g., Intake, Index, Underwriting, Fulfillment), Outputs (e.g., Letters), and Customers (e.g., Insured). Input, Process, and Output metrics should clearly illustrate how you will measure success based on cost (e.g., #hours spent), quality (e.g., % NIGO), and speed (e.g., TaT).

 

Next approach each workflow step in the as-is process to highlight input systems (e.g., online application system, workflow system), activities (assign, approve), and pain points (manual, incomplete).

 

Starting with this approach you now have a clearer road-map to designing the target state.Adding roles and timelines, you then create project charters that ensuregoals are realistic and feasible, scope manageable, and project plans focused.Teams discuss and agree to implementation methodology (agile vs waterfall) as it applies to further analysis, documentation, mock-ups and demonstrations. Assumptions, constraints and dependencies are reviewed, and communication plans and risk management plans established. Stakeholders finalize scope and approve implementation.
Attachments (1)
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
ross harling Accepted Answer

Yes it is worth capturing the As-Is for all of the reasons above and a few more. First, if you don't have any measures for what is happening today, how will you objectively know how by much it will be better, faster, cheaper tomorrow? Next the Future always takes some time to arrive, so why not get the organisation into 'Change Mode' by fixing some of the smaller, easier issues first and gain some early paybacks ? And, sometimes, there are worthwhile benefits from the cumulative impact of small changes. Entropy, like household dust, just gathers in the corners of a lot of business process, and a spring clean every few years can work wonders!
Comment
Maybe it's because I am interpreting terms in another way, but I think 'measures for what is happening today' is not the same as 'capturing the as-is process'.

Measuring is what it should start with -> how well is this process performing? Does it do what we promise?

If you don't know that there is no reason for capturing/modeling/mapping/mining the as-is process, because you don't know if the process is performing bas.
  1. Emiel Kelly
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Pritiman Panda Accepted Answer

In most cases "Yes", unless it is a rip-and-replace kind of development with a all new business process and features, with no take aways from what was built in the past (totally tangential)


Understanding of the AS-IS process helps in:

[list]
[*]
getting better clarity why the system/application was built and what were the business objectives in mind
[*]
realization of benefits in terms of optimizations and other changes implemented as a part of the TO-BE state - helps in getting a feedback and efficiency factor - what we gained and what we lost


  • Operational Benefits, Efficiency, Performance, Process Optimization Stats in the journey from AS-IS --> TO-BE
    [/list]


[*]
reusability of the services , customizations and interfaces that were built in the AS-IS state
[list]

  • For building better and faster Go To Market (GTM) solutions it is important to understand-absorb-prioritize-replicate the components where we have succeeded in the past than re-inventing the wheel
    [*]
    This saves time, effort and revenue
    [/list]


  • [*]
    a reference source for any issues or blockers
    [list]

  • the AS-IS process is something that has been proved and has been through the entire journey till PROD
    [*]
    With a heads up on the AS-IS state of the process - it helps us take precautionary measures or take resolution steps for any similar issue witnessed in the past (considering the AS-IS process was working perfectly fine in the same environment -and has already been proved correct and stable)
    [/list]




  • It is good to start fresh on a blank page and build everything from scratch, with no inference from the past AS-IS process.


    But in an ideal realistic scenario : It is a tradeoff between Time | Effort | Revenue | GoTo Market needs | Investment of the Past
    Comment
    1. more than a month ago
    2. BPM Discussions
    3. # 9
    Bogdan Nafornita Accepted Answer

    I will take the risk to disagree with the overall conclusion of this thread. I may be awfully wrong since I am not a consultant dealing with large projects at large customers and usually I know more about AS-IS process discovery than the usually weak BPM analyst in front of me (I have very few virtues - and patience is not among them).

     

    But I will disagree from one perspective only, which is:
    [b]technology[/b]
    .

     

    1/ The business world is on a furious digitalization spree. It's a wild west land grab right now. I read today a piece that said the average American company uses about 14 SaaS apps to address business workflows, starting with collaboration, through CRM, marketing, operations and finance, to HR. This average company would not care that much about proper entarch or integration - let alone plan for thorough analysis of its processes. This world is changing so fast, that maybe one year on 3 out of the 14 apps it uses are no longer available, having been bought, having pivoted to a different direction or having gone bankrupt.

     

    We as BPM practitioners must adapt and compete with this bubbly, sizzly, reckless market - because this is where the BPM potential is. We may still enjoy playing with the big boys and the big toys in our enterprise castles, but change is coming.

     

    I don't see BPM competing in this market by doing the proper AS-IS, by running the Rummler-Brache methodology, by training employees about the 7 types of waste, about the heuristic BPR techniques or about the Utterback-Abernathy Phase Model. Patrick said that the AS-IS analysis is a good business process training. I can relate to that as a trainee 10 years back. Not anymore as a trainer today. I cannot recall one recent trainee that could remember the above concepts one day later (let alone apply them consistently in their daily jobs) - I also do not rule out that I am a lousy trainer.

     

    Business actors today are digital consumers of byte-sized experiences, be those texts, media or apps. They are far too impatient to RTFM, far too impatient to stay on a site for more than an average of 8 seconds. We, the old school, think this sucks. But it's the reality and we must adapt.

     

    2/ When it comes to BPM tech, today we are spoiled for choice - we can use cheap and competent BPM stacks to deploy process apps on the go. We have the ability to use those stacks in highly agile scenarios.

     

    I am a strong believer in fast process iterations as a way to make systems and people converge. I have been experimenting with this as a customer and I am experimenting with this again now as an implementer. Make an initial, incomplete, but executable iteration and let these impatient people just dive into the process app. Live, in production, no excuses. Let process actors "get it" as they do it.

     

    They start debating about the proper reports without ever hearing about information design; they start suggesting ways to make the process faster and smarter without having to learn about
    [i]muda[/i]
    . There is a certain virality about their contributions once they reach a tipping point. With the right guidance, this is not a myopic exercise. Processes have business objectives, resources are limited so work tends to organize itself if properly "guardrailed" by the right BPM stack and the right coach. I guess there has to be some grand, converging, design principles even in molecular biology.

     

    It is absolutely fascinating to witness their genuine reactions while running the v0.1 of the TO-BE process - I could never get the same sparkle in their eyes in an AS-IS analysis.
    Managing Founder, profluo.com
    Comment
    An almost lyrical celebration of software. "A change is coming" seems to channeling Bob Dylan. No wonder there's sparkle in the eyes of participants.
    1. John Morris
    2. 1 year ago
    Bogdan, I think you've captured my point beautifully (and explained your reasoning better than I ever have).

    The question isn't "when I want to improve an existing process by 5%, do I need to understand it first". Sure, why not. But then, why are you spending your time there in the first place? The real question in: how can I do something new and amazing? You won't find the answer by inspecting the old and mundane.
    1. E Scott Menter
    2. 1 year ago
    @Patrick: no one actually starts with the to-be, obviously. There's a discovery step because there is no single pattern you could slap around on any company as best practice.

    And of course I think of the BHA-BPM-G and then increment towards that - that's what I meant by acting viral but with a sense of a greater design.

    On patience: I was not fortunate enough so far to meet patient customers.

    In this part of the world, things are very volatile: in a matter of days, a club burns -> people die -> other people get out to protest small-time corruption that led to this accident -> government resigns -> big fiscal reform stalls.

    For my customers, patience is luxury.
    1. Bogdan Nafornita
    2. 1 year ago
    Training, "sticking in their head," remembering and, most importantly, practicing, is all about the reps. Most learn by doing and this is about putting more weight on the bar.

    However, on the patience part, I do and will continue to say it's about senior management, executive sponsorship and on the larger initiatives that are shooting at some strategic end-state down the road the good, fun part is how do you iteratively deliver tactical solutions that still incrementally build out to that end-state. Think big, execute small.

    The teaching part I'd have to reserve judgement on 'til I saw you in action. ;)
    1. Patrick Lujan
    2. 1 year ago
    Once again, I would emphasize spending way more time, do the heavier lifting on "to-be," "future state," whatever you want to call it, than as-is, but the past is handy to know in terms of "what do you do now and why do you do it that way," then going into three year-old mode and continuously asking "why?" until they don't have an answer any more. Invariably at the bottom of that pile is a broken process and more often than not it's an organizational, people problem, not a technology one.
    1. Patrick Lujan
    2. 1 year ago
    @Bogdan, your comment regarding patience being a luxury for your customers has been haunting me since first reading. Patience is a virtue I'm sure, but for many people the freedom to be patient may be illusory. Action is needed, but it's easy to get comfortable. The urgency of intelligent action is easier to see "in this part of the world", as you say, where it's more difficult to be comfortable.

    The failure rate of Fortune 1000 organizations over the past generation is evidence of many things, but I think in part due to the processes we are discussing here. Systems may appear solid, and staff become complacent. Until the brittleness is revealed.
    1. John Morris
    2. 1 year ago
    1. more than a month ago
    2. BPM Discussions
    3. # 10

    I am with Walter and Jim.


    1) The top levels AS-IS is the must as an enterprise-wide project. Just be very clear how you define these levels – see ref1


    2) Working with deeper levels depends on a particular business domain. Possible variants:


    a) we don’t have any good processes, please start with TO-BE


    b) we have perfect processes, please, start with AS-IS and just automate them a bit


    c) we have processes, we want to change them but without their digitalisation we can't innovate them, please start with AS-IS, automate/digitalise them to better understand our options and then transform them.


    Thanks,

    AS


     
    References
    1. http://improving-bpm-systems.blogspot.ch/2015/06/incremental-transformation-to-digital.html
    Comment
    And to Brother Sinur and yourself both I would say, re-iterate "it's about the audience and the objective."
    1. Patrick Lujan
    2. 1 year ago
    1. more than a month ago
    2. BPM Discussions
    3. # 11
    Amy Barth Accepted Answer

    Maybe working in the public sector gives me too specific of a background, but the as-is process review (perhaps not really necessary to be "meticulously" documented or reviewed ad nauseum) is absolutely necessary as a jumping off point. It's the introduction to the history, progress, problems, and background as to why you are there to fix it/improve it. It gives the SMEs a chance to remember anything they may have forgotten to document before, to discuss all the requirements/limitations of legislation, and to give insight to their own ideas about how their crappy or convoluted process could be improved. It gives the new analysts and developers a chance to play devil's advocate or at least provide an agnostic viewpoint when asking "why are you doing that" or "what about x?"


    Is it possible to spend too much time doing this? Yes. Can the nitty gritty detailed review of how the current system peforms some specific function be saved for a future requirements review? Yes. Is the documentation of the as-is sometimes required as a milestone deliverable? Yes. And that's okay, although it can certainly be an exercise that wastes more time than it should. I think you'd be hard-pressed to improve something without knowing what you're starting with.
    Comment
    1. more than a month ago
    2. BPM Discussions
    3. # 12
    John Morris Accepted Answer
    I always liked the phrase "paving the cowpath" for how it captured a certain (not necessarily wise) way of automating a process. That said, and acknowledging that sometimes a revolution is necessary, the cowpath embodies so much of the tacit on which work depends.
    Comment
    Yep, I've always been partial to, liked "paving the cowpath" myself. :)
    1. Patrick Lujan
    2. 1 year ago
    1. more than a month ago
    2. BPM Discussions
    3. # 13
    Abdulazeez Sadeqi Accepted Answer

    In my opinion, this is dependent on the objective of the company and its strategy. For improvement studies of
    [u]existing processes[/u]
    , it is necessary to understand the ‘As-Is’ to identify the issue in a scientific manor. I have experience where I have done process improvements (Fast improvement) where ‘As-Is’ processes where not studies and I based assumptions on experience (you can call this a hypothesis) at the end it ended up being a correct judgment, but it could have been the other side.


    We are at the point that things are changing so fast that judgment is needed in some cases and time spent on 'as-is' is not given. I prefer doing it correct and studding the ‘As-Is’ but we are also faced with a realistic world that regulations as an example,are forced on you and the time given to assess As-Is could jeopardize the process the project timelines, so we are forced to judge.


    My other point is that if your organization are introducing a new product or service, in this case there is no ‘As-Is’ only ‘to-be’


    Azeez
    Comment
    1. more than a month ago
    2. BPM Discussions
    3. # 14
    David Chassels Accepted Answer







    I agree with Ross how can you improve something of you do not understand the something….? Interestingly our experience often shows that the managers often do not really know what people actually do and the exercise of exposing current processes often reveals surprises for all! That then opens the door to discussion on is there a better way and again this knowledge will likely lie with the people actually doing the job. So there should be a serious purpose to understanding the “as is” otherwise users’ cooperation in the bigger picture might be a challenge! Also never forget compliance/regulators who will want to know both current process and may have a view on changes.


    As I have pointed out next generation build can be undertaken via the process model and this not only brings benefits of transparency where “the Map is the App” but it builds enthusiasm from users who can now contribute direct to implementation to new ideas. Another consequence is by mapping out the process there is by default a knowledge transfer whereby the process is then owned by the business not in the closed book of users protecting their “territory”….. Yes it happens and can be an issue to address.









    Comment
    1. more than a month ago
    2. BPM Discussions
    3. # 15
    John Morris Accepted Answer

    The debate on BPM methodology concerning as-is versus to-be is
    [u]at the core of the meaning and future of BPM[/u]
    .


    Why?


    Once-upon-a-time work processes were owned by skilled labour, trades people and engineering, including plant managers who were all former engineers.


    The capitalist bargain was "
    [u]we'll provide the capital and you'll provide the labour[/u]
    ".


    Since Henry Ford however, management has been intent on rationalizing the labour part of the deal - and not a bad thing given the standard of living many enjoy as a result. But as the history of Taylorism and industrial engineering shows, for many reasons work rationalization has been severely limited and
    [u]often over-sold[/u]
    -- and un-rationalized
    [u]tacit knowledge[/u]
    of work has remained as important as ever, at least until the present.


    BPM technology is the
    [u]core technology that carries the burden of this dream of management rationalization of work[/u]
    . It is in this context that our debate about "as-is" and "to-be" occurs.
    [b]Because both as-is and to-be are the expressions of management's drive to rationalize work[/b]
    .


    I see three determinants of further progress in the successful application of BPM to work automation.
    [u]Each one of them turns signficantly on the as-is/to-be question[/u]
    .


    1) CORPORATE GOVERNANCE - As-is work processes are contested terrain in terms of giving up work autonomy and tacit knowledge -- and the
    [u]wages that accrue to that tacit knowledge[/u]
    (see Amazon warehouses for example).


    2) BPM METHODOLOGY - To-be BPM is all too often a Platonic fantasy - and the subject of jokes and war stories in the bar after work. On the other hand, new process mining starts from the as-is, and because process mining is itself technology, goes a long way to
    [u]solving problems of learning how tacit work processes actually function[/u]
    .


    3) BPM TECHNOLOGY - Improvement of BPM technology is continuing, to the point that real-time "
    [u]what you draw is what you execute[/u]
    " is viable and the round-trip latency will become a thing of the past. The implication is that through process mining and better BPM software, the
    [u]distinction between as-is and to-be will diminish[/u]
    .
    Comment
    1. more than a month ago
    2. BPM Discussions
    3. # 16
    • Page :
    • 1


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