Resolved
1 votes
In your experience, what works best for capturing business processes?
Tuesday, July 22 2014, 09:45 AM
Share this post:
Responses (20)
  • Accepted Answer

    Ian Gotts
    Ian Gotts
    Offline
    Tuesday, July 22 2014, 09:54 AM - #Permalink
    Resolved
    3 votes
    If your goal is to transform the business and engage all employees, then a top down, hierarchical mapping approach is required using a very simple notation which is easily understood by everyone, and conducted in live workshops. If you want to automate a discrete process to improve compliance or reduce costs, then a single level BPMN diagram should suffice. The two are of course, not exclusive. You can start top down, and then at the lower levels, when you have identified the best areas to automate you can get more "technical" But remember, "automate" is before "discover", understand" and "simplify in only ONE place - the dictionary.
    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 22 2014, 09:56 AM - #Permalink
    Resolved
    3 votes
    We use an iterative process. Starting at the high-level we steadily cascade down through the layers. We use a modelling using a tool tracks the hierarchy of processes and keeps tabs on loose ends. It represents the flow of the work as well as the data collected along the way. The tool is user facing and we find that users are able to work with it themselves to modify and add the nuances of their process. As the tool collects user "wants and wishes" and documents the business rules at the same time it becomes an invaluable, searchable resource as we pivot to process design and implementation.
    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 22 2014, 10:00 AM - #Permalink
    Resolved
    4 votes
    We very much recommend an iterative, top-down approach. Focus from the outset on the work to be done, its goals and its milestones--and get agreement from senior initiative sponsors that this is the vision. From there you involve subject matter experts to flesh out each stage of the work lifecycle, modeling process, user experience, data and integration. In an integrated BPMS environment, where the model IS the application, you can immediately demonstrate the operation even a partially specified, skeletal design and get feedback needed for refinement. The same environment generates the documentation which formally specifies the system. All of this can be a big shift in thinking for people accustomed to conventional document->model->implement approaches to capturing business processes, but doing it this way is essential to get the big productivity and agility benefits you should expect from a BPMS.
    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 22 2014, 10:03 AM - #Permalink
    Resolved
    4 votes
    Before considering a "best" method for capturing business processes, You want to think about the goal(s). Are you concerned about timing or duration of a process? Are you concerned about cross functional "hand offs"? Do you want clarity about inputs, outputs, dependencies, and such? Do you want to ensure separation of duties or appropriate internal comtrols? The answers to each of these questions serve to guide you toward a "best" method for capturing your business processes.
    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 22 2014, 10:59 AM - #Permalink
    Resolved
    5 votes
    I'm with Faun deHenry on this: business problem first then process problem responsible for the business problem and only then comes process design. You won't be able to figure out what's important and what's not, won't be able to make right design decision if the business context isn't properly set. As for techniques, I'd emphasise the importance of going to the shop floor. Don't let "domain experts" cut you off from the people doing the job. Talk both to people on the top (business problem) and people on the bottom (process and job problems). Iterative approach is a must indeed. Expect to have 5 to 10 iterations to the mature process design. This is where good BPMS can save a lot of time, efforts and money and what's more important keep the stakeholders enthusiastic.
    The reply is currently minimized Show
  • Accepted Answer

    Brad Power
    Brad Power
    Offline
    Tuesday, July 22 2014, 12:14 PM - #Permalink
    Resolved
    3 votes
    The best method for capturing business processes I've ever seen is my friend Guy Parsons running value stream mapping workshops. It's live improv theater where people get emotionally committed -- they map and understand the current state of an end-to-end value stream, like hip and knee replacements, and redesign it. I learned you can't underestimate the importance of emotional commitment.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 22 2014, 01:13 PM - #Permalink
    Resolved
    4 votes
    VSM, Business process mapping, Top down. Sounds like the 90's. What I do for each process is first identify the customer and: Inject a GPS tracker into his/her body Ducktape a gopro on his/her head Every employee in the company also gets a gps tracker So while the customer is 'walking the process', he/she is followed continuously by my process capture satellite. When it is detected he is close to an employee, the gopro starts filming and everything what happens is recorded in HD quality. Also screen captures of the employees device are made automatically. In case the customer is not close to an employee my process capture drone flies out and films the customer. In this way the whole End to End process is captured. All this information is uploaded real time to the cloud where 34 patented algorithms combine all the information. You think that is cool? The most fancy part still has to come. Because then a robot arm with a BIC pen, writes the information down on sticky notes and another robot arm picks up the sticky notes and puts them on a brown paper in the right order.
    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Ian Gotts
    Ian Gotts
    Offline
    Tuesday, July 22 2014, 01:38 PM - #Permalink
    Resolved
    2 votes
    excellent. love your innovative thinking
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 22 2014, 02:22 PM - #Permalink
    Resolved
    2 votes
    Iteratively. We have these great tools--we can rapidly build working prototypes that can be tested and even used in production, and then modified to reflect evolving understanding or changing requirements. Let's take advantage of those tools and leave the analysis paralysis behind.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 22 2014, 03:33 PM - #Permalink
    Resolved
    2 votes
    Just implement them as executable processes, of course. Thanks, AS
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 22 2014, 03:59 PM - #Permalink
    Resolved
    3 votes
    Simple talk to the people who do the work. Talk step by step in their language what is required and what they actually do (or should do they know as the “silly” things they are told to do but adds nothing to achieving objectives). Map directly into a graphical designer build environment and in click button to bring to life their process in hours not days for first cut as a prototype. Once they realise it is that easy you get very quick buy-in - or as we found out on one occasion sudden realisation their "black book" is opened and no longer “their” process. In this case they had "knowledge power" and walked away not going to play the game! Rare but it does happen the human race instinct for survival! Yes getting backing from the top is helpful and should avoid such "behaviour". I am surprised so many start "top down" - how many mangers really know what the process is. With one of our early adopters the manager articulated the process and we then built. We within days showed him the process running. He was so amazed he suggested let’s show to our people. Very quickly they smiled and said no that's not the way we do it! So we changed in front of them and they quickly came on side. So always start with users with backing of the manager. What happened was interesting they just did not want “IT” involved and guarded their system as their own! It was raised at senior management meeting and IT found themselves not knowing about it but wriggle factor saw embarrassment limited! That was over 15 years ago and we learned a lot about the real challenges from such early adopters.
    The reply is currently minimized Show
  • Accepted Answer

    Amy Barth
    Amy Barth
    Offline
    Tuesday, July 22 2014, 05:33 PM - #Permalink
    Resolved
    2 votes
    1. Make friends with a SME. Learn their language/needs/wants/frustrations. 2. If documentation for existing systems are available--read them. Get your SME to confirm that the documentation is valid. 3. Discuss the project at hand in their language. Ask them multiple times if you understand correctly. Show them a picture and give them a chance to confirm/add/update the process. 4. Assuming the methodology is agile, prepare them for regular involvement, and get their feedback as often as possible. Don't blame them for forgetting to tell you something as the process unfolds. We are all just human. But ask as many questions as you possibly can before you get too far down the road to try to prevent this scenario. 5. If something is overly complex, ask why. The SME probably knows how things got complicated. Offer solutions as you are able. Relationships and rapport go a long way.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, July 23 2014, 07:02 AM - #Permalink
    Resolved
    6 votes
    What is the best method for capturing business processes? Well before we start on arguing about “best”, let’s decide which process really matters. Some people hold up the idea of getting everyone together and asking them to outline their process, then agree what it should be. This collaborative method leads to groupthink and choice of a process which offends no-one, rather than which delights someone. And it rarely gains much in efficiency (turkeys and Christmas etc.) Close behind is the guru method. This is unfortunately bound up with the consultants system, where people are paid to tell companies what they want to hear. That means not shifting them out of their comfort zone. Both address a symptom, not the problem. There is a fundamental decision. Do we want to keep doing it wrong – but just faster, with fewer errors and fewer people? Or do we want to look at what we are trying to achieve and reimagine how to do things to achieve it. A fact of life is that they wouldn’t have brought you in or embarked on a process improvement process if it was working. It probably doesn’t need to just be 10% faster, use 10% fewer people or produce 10% fewer rejects. It is broken. And if you simply “improve” it, you’re really making it worse. Because you are making a whole generation of managers say “we’ve done that, let’s fix something else”. So you need to start somewhere different. Not with capturing an existing business process, but with working out why you need one. That means the big picture (yes, I know you haven’t a budget for doing that). Finding out what the customer really wants (not what they think they want). Finding out what the managers think the process is for (it usually isn’t what it does). And finding out how important the process is to the business (that hierarchy usually isn’t right either). Some simple considerations too. Where can you get data? What is the internal dynamic – who’s blocking you and who’s backing you and which is stronger? How fast can you move opinions – if you launch it all at once, it will almost certainly fail, but there may be three steps or three hundred. Those are the business processes you really need to capture. How does that company makes decisions, how did they get themselves in the mess in the first place and what will change their minds - have you really fixed that process or will it recur and wreck your project? Once you’ve captured and repaired that business process you can work on the symptom you were given as “the problem”. Capturing that first doesn’t fix anything. So the best method is not to capture it efficiently, but to use it to expose the real problem. That's the real reason why collaborative methods are important.
    The reply is currently minimized Show
  • Accepted Answer

    BPM Mentor
    BPM Mentor
    Offline
    Wednesday, July 23 2014, 11:15 AM - #Permalink
    Resolved
    2 votes
    Dear Peter, your question is asking for the elicitation techniques inventory! The analyst will choose the best one(s) fitting the context: - Survey: interview, questionnaires - Creativity: brainstorming, analogy, change of perspective, De Bono - Document centric: system archeology, reuse, perspective-based reading - Observation: field observation, apprenticing - Support: workshops, mind mapping, audio-video recordings, use case modeling, prototypes The analyst must balance out the strengths / weaknesses and pitfalls of the chosen elicitation technique(s).
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, July 24 2014, 05:14 AM - #Permalink
    Resolved
    2 votes
    I am suprised that no ones seems to have latched onto the CAPTURE verb ... Peter did not ask about analysis or disocvery. He asked about 'capturing' and that means that Emiel's humorous approach is the only proper answer here. All the rest are BPM-expert-platitudes and in the end do not capture a process. Well, as some pointed out the point of BPM is not to capture a process. And further, if we talk about designing a process why is there only one reference to goals, outcomes and handoffs? These answers show quite clearly why doing BPM analysis and implementing BPM processes in software is such a mess and brings little real benefit to the business. If you disagree don't flame me, but simply deliver the vendor independent BPM studies that proof that it does benefit a business in the long term. I have been asking for these for the last twenty years. One key point is that the iterative approach is good, but using orthodox BPM techniques and software to do it requires a huge bureaucratic overhead. And the fact is that a process is NEVER complete and final. Like the environment it fits into it has to adapt continuously. There go your promised productivity gains and cost savings in the long term. Both goal-orientation and iterative adaptation have to be activities that do not require a BPM expert. Peter asked lately about adoption and thats where the trick also for process capture is. The business has to willingly adopt BPM as something that makes their life better. Current BPM does not. It creates fools with tools. You need to be able to capture processes without having to analyse/design them upfront. One has to design and analyze the framework and ontology that allows the business to describe its processes and access the necessary data and content that make it a usable real-world process. A flow diagram does no such thing. Once that has happened the business can capture its processes by simply performing the work in the process environment. If the business users can adapt while working and then reuse what they adapt, the iterations cost very little and go very quickly. Yes, there is nothing wrong with a process expert playing the coach here and supporting this effort of the business. This means that the questions why (goals), who (responsibility) and what (data, content) are to be answered by the business management to segment the processes into verifiable goals, to deliver outcomes and handovers. The HOW is captured through the business performers while doing what they do. Once the capture is done once, the continuous adaption by the same performers to achieve the goals quicker, cheaper or better can do its magic. The why, who and what is mostly designed top-down, while the rest of the process is captured and improved purely bottom-up. Today's BPM experts are so blindsided by the orthodox methdologies and so limited by current BPM software that this approach is not the most common one as it should be.
    Like
    1
    • BPM Mentor
      more than a month ago
      I read your answer... what is your answer saying? Bottom-up as a capturing method? Sorry, I don't get it. Moreover, give us your definition of "capture" in the context of Peter's question - things will become easier :-)
    • Dr Alexander Samarin
      more than a month ago
      There are a few meanings of the verb “capture”
      1. Take into one’s possession or control
      2. Record accurately in words or pictures
      3. Cause (data) to be stored in a computer

      I think you use the second or third meaning. I interpreted the question as gaining control over processes (to better manage an enterprise), of course, during their whole life-cycle.

      Thanks,
      AS
    • BPM Mentor
      more than a month ago
      Maybe Mr. Pucher will also find the time to continue the dialogue. Thank you Alexander.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, July 24 2014, 11:56 AM - #Permalink
    Resolved
    2 votes
    I am with Max and BPM Mentor. The first question is why are you capturing this process - not at holistic level - but is it the AS IS state or TO BE state. For As Is, the best way to capture it is quickly - through observation, team meeting to build the AS Is and get commitment, and butcher paper or software tools. The point is the AS IS is the way it is today and you are going to use that to analyze and improve it, so it doesn't have to be perfect. If you want to capture the TO BE, it could be just a 'model' of the future, so use your standard tool. If you want to know current data of the process, then you need to have it in a form (BPMS probably) where this data will come off the actual real time flows.
    The reply is currently minimized Show
  • Accepted Answer

    Tim Bryce
    Tim Bryce
    Offline
    Thursday, July 24 2014, 02:03 PM - #Permalink
    Resolved
    2 votes
    Here is an article I wrote on "Current Systems Analysis" some time ago. Should be helpful. http://it.toolbox.com/blogs/irm-blog/current-systems-analysis-25446 All the Best, Tim Bryce Palm Harbor, FL, USA timbryce.com
    • Tim Bryce
      more than a month ago
      In our "PRIDE" Methodology for systems design, we have a rule whereby a sub-system (aka Business Process) may have no more than one computer procedure. Consequently, if I discover a computer procedure, I have also discovered the sub-system. For batch related processes, this is relatively easy to detect simply by looking for those program(s) scheduled for execution. This then helps define the hierarchical structure of the system (both the sub-systems and programs).

      As an aside, in the old days, you could find this quickly simply by looking at your JCL decks (or whatever your command language happened to be).
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, July 24 2014, 02:09 PM - #Permalink
    Resolved
    2 votes
    User stories/use cases would seem to be the most natural way to analyze a problem domain for its business processes. Related business processes will emerge once affinity analysis is performed on the US/UCs. Another approach is to leverage industry models as a starting point for business process definition. Communications and other digital service providers (DSP) can leverage TM Forum's Frameworx models as a starting point. Other industries certainly offer similar mechanisms and gov't-funded projects (e.g., USA's Health Insurance Exchanges) may prescribe the business process model already.
    The reply is currently minimized Show
  • Accepted Answer

    Tim Bryce
    Tim Bryce
    Offline
    Thursday, July 24 2014, 03:04 PM - #Permalink
    Resolved
    2 votes
    Something else - "Only when the Systems Engineer can walk in the moccasins of the user does the engineer have a right to design a system for the user." - Bryce's Law
    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 29 2014, 06:49 AM - #Permalink
    Resolved
    3 votes
    For over 30 years I have been 'capturing' business processes in organisations in all types, sizes and geographies. As some have already pointed out the often overlooked ability to stop, look and listen are useful aids in making a successful capture. However processes can be tricky beasts; often hiding away in dark corners of the organisation, or camouflaging themselves as useful, productive work when they are really wasteful and unnecessary activities. When it comes to tracking the paths and vagaries of such processes, people working in its immediate locality almost always have a much better understanding than their chiefs. When language differences become a barrier to shared understanding, then creating a diagram is the most immediate and effective solution. However, before creating such diagrams it is vital to first plan out a set of meaningful icons and representations so that diagrams created elsewhere, or by other members of your team, can be quickly and consistently understood. By collecting diagrams of all the processes and fitting them together, one can then create a 'map', thereby tracing the origin of each process through its various stages, to its conclusion and a hopefully useful outcome. By examining this 'current state' map, one usually discovers some processes which meander endlessly through the organisation for weeks or months consuming resources along their way. Other processes might begin for no apparent purpose and end with no discernible outcome; a waste of time, money and effort for all concerned. Many improvements are blindingly obvious when viewed within the end-to-end map, generating 'quick wins' and saving for the organisation without any delay or significant effort. The viewing of such a 'current state' map by chiefs and workers alike, often creates shared understanding for the first time. Floods of questions arise, such as 'Why do we do that?', Can we be more innovative with this?' If cannot innovate how do we avoid or improve this process? And, most importantly, "How can we optimise all of our core processes to deliver more value for our customers, our people and our stakeholders?" The 'current state' map and its realignment with the goals and values of the organisation, can then be used as a solid platform on which to produce a 'future' or 'desired state' map. The future state map shows how the organisation will work in the future, how processes can travel far faster and deliver their value more effectively; and how new process superhighways will bypass the clogged and congested departmental backstreets of old. Once again, the sharing of the future state map with all involved, creates a shared understanding of which processes are key to the organisation's future success, how they will work in the future and what new skills and capabilities will be required. So why is visual diagrammatic mapping the best means of capturing business processes? There are many reasons but the four most important are: 1. The mapping process itself is inclusive and everyone participates. 2. The 'Current State' map identifies immediate savings which often outweigh the cost of producing it many times over. 3. The redesign and shared viewing of the 'Future State' map creates an understanding of the organisation's next destination and the reasons for making the journey. Finally, together the 'Current' and 'Future' maps and the work undertaken in creating them provide a solid foundation for the management of organisational change. But that is another story, Ross Harling, Process Hunter, and originator of Atticus Enterprise Mapping.
    The reply is currently minimized Show
Your Reply

Join the Discussion

Want to join the discussion?

Login, or create an account to participate in the forum.

Top Participants

Dr Alexander Samarin
276 Replies
25/09/2016
David Chassels
269 Replies
23/09/2016
Emiel Kelly
220 Replies
23/09/2016
Bogdan Nafornita
209 Replies
25/09/2016
E Scott Menter
182 Replies
23/09/2016