Tinkering with real world BRPs (Barely Repeatable Processes)

The other day I was asked to framework a neat and natural flow that could sort out a daily but important practice for a large organisation. Currently the practice is, as usual, only supported by a sprinkle of request and bug tracking systems, email, calls and meetings.

(Note: Thingamy is a framework and comes empty, each business practice or process must be built bespoke. Luckily nothing that takes much time, two to five hours for even complicated practices.)

OK, here's the issue: In any organisation you have machinery, equipment, computers, software, people and processes - and amazingly enough, not everything works all the time. Duh.

At least that's how we users see it. Reading the manual is for sissies, things should work like we're used to dammit.

And stuff does not have to be broken, annoying is as bad. Time consuming or plain stupid processes makes me go "arghhh!" as well.

Of course stuff has stickers with help line numbers to call where you can listen to muzak, software has bug reporting systems where everything can be dumped into the lap of frustrated developers. And as a last resort you have a supervisor who nods and promises "to do something about it".

See the problem here?

Help-lines who have to struggle with people who forgot to plug in the monitor, bug reports that could have been solved by RTFM. And supervisors who has to go to his boss, who has to go to his boss before the issue transcends the organisational silos to where it perhaps could be solved. As if that ever worked.

Now you see it?

So, taking a cue from real life practices, like hospital emergency receptions, we built a proper flow from report to solution using a system of appropriate triages - allowing for any kind of problem from "oops forgot to plug it in" to good ideas for changes to business processes to be appropriately addressed by the right person at the right time. And once started nothing can stop it while all can see what's up, so no way to avoid accountability and pressure to fix asap.

The best part was that I found yet another business practice that is amazingly similar across utterly different types of business or size of organisations.

For me that means a "template" that I can easily tweak to become bespoke. Almost like having a out-of-the-box application using our framework. Does not matter if you're in production, transport, services, software, tech, whatever, stuff breaks apart everywhere. And, come to think of it, any random group of co-workers at lunch will always bitch about something that needs fixing, so why not have a proper system in place so the fix will happen?

BTW, if you're not easily bored, here's a 8 minute demo of one version.

Comments

[Luca Manassero]

I very much liked that demo, Sig. imple and powerful enough to support most real world issues.
I would probably consider adding the option to bother people whenever issues are waiting for their attention, thou. Something like pinging their PDA's, iPhones, or whatever. Bypassing e-mails, as everybody gets just too many to pay attention to 'em anymore.
Waiting for pepope to log into a systems supposes a "setting" which is not always actual.

All in all: absolutely GREAT framework, as usual. Possibly to be combined with a PDA client, pinging you that an issue needs attention.

See you soon :-)

[sig]

Thanks Luca! :)

But of course - there is (hidden for the time being) an email setting interface in the builder interface for tasks so you can set text to be sent and so forth.
Not far from there to SMS either, and RSS is a breeze.

The reason why it's not implemented is the need to set up the server for it - and that's not so practical when doing lightweight demos and pilot implementations! But it'll be there...