The last project was all about process documentation. To be honest, these are not exactly my favorite kinds of projects, mostly because they can be easily associated with long hours of unthankful, tedious work.
Why tedious? Well, one reason is that process documentation tends to have large volume, while efforts required to produce it are mostly not automated.
I was wondering if there is any simple way to streamline this kind of jobs, aside from hiring more analysts or investing in a some BPM software package, which would probably be an overkill for most of the projects I did.
Making any amendments to the processes is especially pita, due to all the custom diagrams interlinked with detailed textual content.
(that is if you use diagrams + text – sometimes just slides are used, especially for high-level documents – I think text is much more flexible if you need to accommodate more information)
While in fact, amending the design based on remarks from business users is the core of process-related projects.
Process-related projects shouldn’t be such a chore – if you take away all the time wasted with Microsoft Office, these projects allow to get the best idea of how the business really works.
Looking back, projects involving deep understanding of processes provide most powerful references today.
The kind of customized process work that is done during relatively short strategy project shouldn’t be mistaken with implementing whole “process-driven” approaches in the company, for which elaborate business process management IT solutions exist.
The idea is to store process designs in central repository, where they can be easily versioned, accessed by large groups of employees (which can be assigned different access rights), monitored, and modified.
Truth is – maybe it’s because it’s Eastern Europe and we are backwards – I never saw any of these system in real world use at any of the clients. Perhaps they are more popular in production company than the financial sector. I remember one Russian client mentioning before the project started that they had one, and that deliverables (processes to a large extent) would eventually have to be integrated in it somehow, but it was the only time the topic emerged.
I think there are plenty of good reasons for such solutions to have difficulties in real life adoption.
Enabling new users (like external consultants) to access the system requires at least creating new logins, in worst case it might require to buy additional licenses. Hardly easier that just emailing process documents.
People are used to work with Word or Powerpoint documents, but might need time to master unfamiliar interface of the process application.
Even though usually it should be possible to export process information in format like PDF, it might not be possible to export in format that is editable, so ad-hoc participants can contribute remarks.
The reason are many and truly converting organization to be managed around a consistent BPM system must be a daunting task. And partial implementations often leave orphaned systems that are not used.
For now, I was rather thinking if there was any way to improve the way stand-alone process documentation is created, rather than an end-to-end system.