My company has decided to run a project to map all of our operational processes and maintain a repository of these 'as is' processes. I believe that the processes will then be used as the starting point for any process improvement projects and once a process has been improved, that new process will be included in the repository. I don't think the company plans to use the process repository to manage our processes.
I'm interested to know what others think of this idea and if they think it would be valuable. I question whether it is better for an improvement team to start from scratch and develop the 'as is' process with the team so that everyone gets a good understanding of the process rather than with an 'as is' process that is handed to them. I also question the value of the repository when taking into account the effort and resources required to maintain such a repository.
Also what format should the process maps in the repository take? Depending on the audience the maps could show a middle level view for future improvement teams, a detailed view for users of the process to know what steps to take or a systems view showing the IT systems and information exchanges.
I would be very interested to hear if other organisations have implemented a process repository and the value it is delivering or any thoughts about this subject. Saving Changes...
Sort By:
Anonymous
With my business, changes are constantly being made to processes. To have a repository of "As Is" processes, in my opinion would be a waste of time since they would change as fast as they are documented. I agree in the value of the improvement team documenting the latest "As Is" in order to understand the process they are impoving. Once we begin "As Is" mapping it mandates a freeze on any changes to the process without project champion approval. A repository of "As Is" would be difficult to manage. A repository of improved processes with process owners may be of value so individuals know who changes to the process have to be approved by before making them. Saving Changes...
Anonymous
Keely,
As a consultant who has gone into organizations to recommend new technologies, written and mapped processes are important and very useful forms of process documentation. With processes written down, it is much easier to determine what software and hardware a company or government agency needs to implement. Without written processes, the consulting team must spend extra time creating the information or guessing about how one business unit works with another and with external customers. Even if processes are out of date they have value for the needs assessment process.
Internally, I think that they help people understand and learn their jobs. They are critical when a person leaves the business or transfers to a new position. They can prevent newbies from asking the same questions over and over and worst, making mistakes that could have been avoided.
The best way to manage processes in my opinion is with a database that allows users to quickly search for keywords and other metadata. If well built, a database will also allow users to view documents and images that are stored as unstructured information. Another reason for using a database, even in a small office is that several people can access and edit the information. An HR specialist can review employee relations information, a line manager can improve operational efficiency, and an executive can ensure that workflows continue to help improve the bottom line. Saving Changes...
Annette KesslerQA Analyst| Seattle City LightBrier, Wa, United States
In our IT department, we keep documentation on "as is" processes as part of our source code, which is also available for the support team to access or augment support documentation. Every time an IT project impacts the process, it is updated.
From my recent experience in a disastrous and wasteful project, I do not recommend starting fresh and rewriting what you have. It would be useful to sit down with your business unit SME's and review what is available to determine if it is accurate.
There is always a need to know what the "as-is" process is before developing the "to-be" process. The gap between the two drives your requirements. That being said, I can add two experiences (I'll try to be brief).
In the first, I ran a project in which I was new to the company and was told there was no existing process. "This is something we've never done before" they said. Making the long story short, they lied. I doubt it was intentional, but they had a home-grown "monster" they used and somehow they weren't tying it to the new product being brought in. Had they been required to document the process beforehand, they would have made a project significantly smoother.
Second experience: Again, we were bringing in a new product, they type of which had never been used in the organization previously. This time the folks were smart enough to realize that, yes, they had done this before - sort of. They realized that because they had been required to document the process the previous year. When the product vendor came in, a lot of the work was done and what was left was mostly product-specific details.
Is there value in doing this. Yes. Is it expensive? Yes. Will it get behind or out-of-date in some cases? Yep! However, it makes a great tool for orienting newbies; it's a great way to find unnecessary steps, out-of-date pieces of the process, etc.; and it's a great jumping off point for a new projects in any area.
Document the process as it is right now, including the good, the bad, and the ugly. Starting from scratch and developing the as-is picture is really creating the to-be. So just doument the current process in each area, and then the execs will decide which should be "refined" and in what order.
Good luck! Saving Changes...
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
Keely, it is critical to map the existing processes but even more critical is to map existing issues to those processes that impede the achievement of management's key objectives. In doing this you start to understand the alignment GAP between how current processes function today and how they need to function in order to support the goals of the business.
I undertook a repository project a few years back and used Lotus Notes to catalog every process within the organization (using Helix of course). What resulted was a tool that allowed us to zero in on high cost processes where streamlining could yield maximum results. It also helped on governance issues as every job description was mapped, every regulatory related item mapped, etc. It then became very easy to research the impact of a change to a regulation or internal control weaknesses (segregation of duty stuff), etc.
The original goal was to support expansion so that new divisions could pull out best process practices with supporting job descriptions, policies, etc.
Hope your project is going well, remember, I am here to help. Saving Changes...
Brian HillCISA, AFCHSM. CEO| Laughing MindMorpeth, Nsw, Australia
Absolutely! I've been involved in a range of BPI, BPR projects over the years, and having a solid understanding of as-is processes, as others have highlighted, is a critical starting point. In larger enterprises, where processes have evolved organically and reflexively over time, you'll find these are documented in all sorts of formats, with change control, filenaming usually applied in all sorts of forms.
What I've found useful is to be able to provide a process model that allows for progressive levels of drill through that foster, at the highest level, an end to end view of the business. This provides an entry level view of the business that any new hire can quickly appreciate, before starting to focus in on the aspects of the business that relate most closely to their role. Having this sort of view acts as a business-silo inoculant, by connecting up the dots for each end of the business value chain and helping to break down the silo thinking and fiefdoms that naturally occurs in medium to larger businesses.
I've found that using an Enterprise Wiki (like Atlassians Confluence tool) is a great spot for collecting the various mish-mash of pdf's, docs, whiteboard notes etc, (like a content inventroy of as-is artefacts) and then starting to massage that into a more coherent set of easily understood structures. Such an approach also allows you to run integrated risk, issue spaces pertinent to each process or process area (with a tool like JIRA) right next to the processes, which is useful for plotting out the gap work thats involved in refinement and improvement from an as-is baseline.
Getting agreement from all elements of the business on the to-be, or target state, is harder. This requires demonstrating a few possible options, with some SWOT work against each, and can be quite iterative. I did a post on my website some time back at http://www.laughingmind.com/resources/bpi-bpm-bpr/think about approaches that I've used, but the post at http://www.laughingmind.com/resources/bpi-bpm-bpr/why-do-bpi is probably more useful for the purposes of this thread.
My clients are finding the move towards a more coherent, consistent approach of documenting processes is making life easier, and fostering a greater level of agility and cross team understanding-useful enablers in a dynamic business. Happy to talk further on this if needed, please feel free to get in touch with a PM. Saving Changes...
