Also on a TIBCO theme, I had some questions passed on to me that we didn’t have time for on the Q&A during my recent Process Discovery webinar, and I’ll address them here in case you were on the webinar and had the same question. If you were there, you’ll recall that we had a little technology glitch: Webex went down about 10 minutes in, which left the attendees with no visual of my slides (which were pretty minimal) but also left us with no Q&A chat window, so we had to handle Q&A live on the phone. If you want to see the entire presentation with the slides and audio together, the link is above.
Q: I was interested in the point you made concerning the need to document current state. I have found that I have always focused on ideal future state. This is for a number of reasons:
(1) It helps people think outside their silos – current state tends to be a manual on how applications work and how users integrate them. (2) You get a pure business model that does not necessarily have any resemblance to the system architecture. You can then implement this (partially of course) and end up with a more “appropriate” solution than you could have from iterating forward from current state.
(3) Current state is very important from an application architecture point of view to understand your capability when it comes to implementation of fine grained services. Ideal state enables you to create the real value add course grained services.
I am not sure this is a question actually but I was interested in your thoughts/experiences with this.
A: I agree that the focus should be on the future state, but we can’t make the mistakes of the 1990’s-style business process reengineering that completely disregarded the current state and started from scratch; generally this led to major chaos and an unduly long implementation cycle due to the lack of identification of any potentially reusable processes. My usual technique with clients is to do a lightweight review and documentation of the current state in order to drive out the higher-level business goals and metrics, then start a future-state process modeling exercising with a relatively clean slate. The key forbidden phrase in these sessions is “because we’ve always done it that way”.
Q: Can Sandy give examples of a hidden processes within e-mails?
A: I see examples of this every day. On the administrative side, it’s very common to see processes like approval for travel and expense reimbursement to be handled completely in email in an ad hoc fashion, which relies on someone in Accounting to make sure that it went through all the proper approvals rather than having a BPM system enforce that. I’ve seen cases of daily reports being sent to large customers manually by email, even though the same report is sent every day. For a very specific but common example, in many of the mutual fund back office transaction processing customers that I’ve worked with, registered transfers (when you transfer your 401k/RRSP to another financial institution) are almost always handled by ad hoc email processes, even though a complex set of steps must be executed in a particular order. In most cases, these email-based processes started as purely paper-based processes, then the participants decided to move them to email since it was easier than using the paper methods.
Q: My question for Sandy would have been about the “validation” process that she might recommend where BPM is just the first rocky step to integration (of systems, people, authority etc). BPM “discovery” can be the activity that innocently and unintentionally identifies exactly why different departments and systems are not optimized. I have found myself in the situation where multiple BP options exist and I have always tried to maintain a helpful, neutral, facilitative role, but lately have been wondering if the Analyst doing the BPM can act as an advocate for their preferred process? This seems to lead to alienation of (some of) the people you depended on to map and design in the first place…
A: I always find it hard not to “take sides” when I’m doing the analyst role, since as an outsider, it’s sometimes easier for me to see a better solution without corporate politics or organizational inertia getting in my way. Usually I’ll present what I see as a potentially optimal process as a straw man, and force people to tell me why it won’t work. Even though we rarely end up with exactly what I’ve specified, it has the advantage of challenging their attachment to the current processes and having them look at some new ways to do things. After a day or two of beating it up and coming to agreement on what that future state process should look like, I usually like to run it by a larger number of the people who actually participate in the business process on a daily basis to see if they can identify any problems that might occur. As a facilitator, it’s important to keep an open mind since what you think might be the optimal process may not turn out to be that, yet balance that with providing some gentle guidance towards a solution.
Q: Are there any case studies that show how to break down silos to allow process management to occur in an organization? Can I have some sent to me?
A: I don’t have any particular case studies that I can share right now, but it’s possible that TIBCO (the webinar sponsor) may have some. What I’m seeing with my customers is that the ones that are willing to disregard the current departmental boundaries in their company when looking at ways to improve the business processes have the greatest amount success. In terms of how to break down the silos, here’s a few tips:
- It’s critical to start with high-level executive support, since you will definitely be ruffling some feathers about who is responsible for what.
- Look for processes that are common to different areas, and see if that process can be consolidated.
- Map the business processes from end-to-end (at least at a high level), not just the part where they pass through one department.
- Focus specifically on points in the process where it touches the customer or trading partners, since these are most often the things that drive the performance metrics for the process.
- Look at the hand-offs between departments, since these are the most likely points of inefficiency in the process.
- Involve people from all of the functional areas in the high-level process modeling exercise, ideally at the same time in order to capture the interactions between the groups.
The next webinar that I’m doing in this series, Process Modeling, is coming up on July 11th.