I have been working on producing As-Is business process documentation and have gathered some valuable insights along the way while discovering the ways that users interact with the system. These will be valuable inputs to the To-Be process, however that will be treated as a separate phase of the project, initiated at a later date.
My question is, how do we collect and document the inhibitors and process improvement suggestions during the As-Is phase? The Business Process document does not feel like the right place, would you manage these as change requests, another document, or a section within the As-Is document?
Any suggestions or ideas would be much appreciated.
Slojo
Hi Slojo,
They should definitely be separate from the as-is business process documentation. It sounds like you are in need of a backlog of potential improvements/changes/requests. Think of a it as a wish list.
My suggestion is that these should be tracked in a list format so that your list can be sorted, prioritized, searched.
Think about some of the metadata (aka columns) you might want to track for each item in the wish list such as:
* Title
* Summary/Description
* Rationale (what problem you are solving or what opportunity you are addressing)
* Source/Sponsor (the name of the one who requested/discovered it)
* Reference to existing process (here you can link/reference to the as-is process you are documenting and which relates to the line item in context)
* Priority
* Relative Complexity
* Disposition/Status
* etc.
Let us know what you end up using and how it worked for you.
Adrian
Hi Slojo
I've just finished doing exactly that in my current contract.
Just have an appendix in your AsIs document. Put it all in there. I capture most of that stuff under 'pain points'. Feeds into the ToBe nicely. You can get fancy as Adrian suggests if you like but I personally think that's overkill.
Kimbo
brought to you by enabling practitioners & organizations to achieve their goals using: