Being an engineer by training (and at heart) I have always been a bit sceptical of those who say that the law cannot be automated. Yes, there will always be special cases in need of bespoke thinking, but these can be acknowledged within a system. As law involves the application of written rules + historical information, there is actually a large overlap with information and language theory.
Here are a few thoughts as I start looking at this myself. They may not all be “right” and may change as I go along but, hey, they might somehow be useful to someone.
Where to start?
As with most things a first step is conscious reflection. Attempt to look with fresh eyes and then perform a brain dump; this provides a good starting point. I normally do not worry about extensively documenting everything; this is impractical if not impossible. If you build any system in an agile, iterative and extendible manner you can refine later.
A great person to do this is an intern or new starter – most if not all within an organisation will assume that the way things are done is the way things can be done. This is why people hire management consultants (at large cost).
At this stage bullet points are good – they allow hierarchy to be captured. This naturally translates into most data structures.
Law: meet the Internet
Another advantage of web technologies is you can quickly build prototypes and have everyone access them. They are also cheap, well-documented and easy – you can set up a web server on a mothballed PC using the LAMP framework (Linux, Apache, MySQL and PHP) with a few lines of command line code. Hell you can set up a system for a small business on a Raspberry Pi for £50 – silent and 3-5 Watts. This is how the Googles and Facebooks became so large so quickly.
Model Process in a Code-Friendly Manner
Next step is to iterate through your process brain dump adding some structure.
Pick out key events and triggers – model in flow diagrams.
Pick out key documents requiring input – model as bullet point hierarchies. Make a note of where input is actually required, what information may be stored already and how long each input takes to generate.
Think modules – try to separate process and documents into relatively independent elements – ideally each module or level should have 3-7 elements (reflecting the number we can hold in our minds at any one time). If you go above 10 elements – add another layer of hierarchy. It is easier for our brains to work at different layers of hierarchy, each layer having a few elements, and “drill down” than it is to have few layers with many elements per layer.
Pick the easiest modular subprocess. Start with this and prototype independently. Big systems hardly ever succeed (think of any public IT infrastructure). Document extensively – blog internally or externally – it is a great way to document and you get the marketing for free!
Go from the model of the subprocess and any documents to a web-workflow. Documents can become XML then HTML. Presentation can be dealt with later via CSS – concentrate first on functionality. Take key process functions and code-up computer equivalents (e.g. in PHP or other server backend – Python is good for quickly prototyping back-end function). I would avoid extensive database use at this stage – they have relatively high inertia – iterate at a flat-file level until things stabilise, at which point you can look at a database.
Anyway I will try to provide some examples shortly to make this all a little more concrete.