Home >

Systems

You have designed and implemented a pretty good logistics system and are proud of how effective and efficient your aupply line provides your programmes with any materials they need. Transport and administration cost are now at their minimum, fulfilment rates are close to 100%, and you process and fill almost every order within set timeframes. You feel pretty good about yourself (and not without reason), and are ready to hand over the system to your successor with justifiable pride.

And then the ministry of trade announces that as of tomorrow, clearing rules will be changed, adding three weeks to the current four to five days it takes you to clear your goods. Suddenly things look a lot less optimistic: your carefully balanced and trimmed-down supply chain is strained to the snapping point, and you are looking at having some of your key operations suspended. Even worse: one of those is a treatment programme for TB patients, and suspension of treatment might cause resistance to the drugs involved – making a bad situation suddenly look catastrophic. What went wrong? Click to read on.

{

Continue Reading 0 comments }Aid and aid work, Logistics, Public health

Humourless links for March 1, 2010

by Michael Keizer on March 1, 2010

[Image: Liquid Links by Desirae; some rights reserved.]

{

Continue Reading 1 comment }Aid and aid work, Logistics, Public health, The light(er) side

Simplicity, participation, and some tall tales

by Michael Keizer on November 18, 2009

Usually, I find myself nodding enthusiastically when reading J.’s Tales from the Hood; his thoughtful mini-essays on humanitarian aid work (with, as he describes it, “occasional digressions toward rock music, motorcycles, and parenthood”) have from time to time even been known to make me belt out a loud “yeessss!!!”, accompanied by fist-pumping motions that look totally ridiculous on a bespectacled, bald, overweight forty-something.

But this time I found myself frowning, and actually disagreeing vehemently. In his latest article on “rules to live by”, he writes:

Don’t overdo “process.” Yessssssssssssss, process is important. But process is not the actual point of aid work. The point is product, output, outcomes, impacts, benefit to beneficiaries… [INSERT PREFERRED AID-WORLD BUZZWORD]. If your process doesn’t lead to one of those in fewer steps than you have fingers, then it is probably useless and should be fixed or abandoned immediately.

And then:

Don’t overdo “participation.” Sometimes less is more when it comes to group decisions and group-led processes. If you can make the decision, make it. If you must involve others: Involve the lowest number of people practical for operational decisions. Involve only technicians and/or those with direct managerial authority over the project in question on technical decisions.

Of course, of course J. is right that outcomes are more important than process – but I think he overstates his case when it comes to the simplicity of the process. By total coincidence, I posted a response yesterday on humanitarian.info in which I said, “… if your solution can be written on a postcard, it probably solves nothing”. This was the summation of a four-paragraph argument that silver bullets don’t exist, that we need to look at systems as a whole when searching for solutions to issues, and that consequently those solutions will hardly ever be simple. To put it another way: we don’t live in a Hollywood movie; our problems will not be resolved in two hours in a script that can be gleaned from a one-page summary.

It all comes back to what I wrote in my post about ICT versus systems: if you want progress, you will need to do much more than just introduce yet another tool or another procedure – you will need to tackle the system, and on the whole systems don’t respond too well to short, sharp shocks. And all this with the caveat that, yes, of course there will be complex issues that can be resolved in a simple manner – but not that many.

Similarly, although I agree totally that one shouldn’t ‘overdo’ participation, I think that J.’s rules of thumb (“If you can make the decision, make it. If you must involve others: Involve the lowest number of people practical for operational decisions. Involve only technicians and/or those with direct managerial authority over the project in question on technical decisions.”) are overly simplistic. Yes, of course I keep the final responsibility as the manager in charge, but I can use inclusive process[1] to:

  • build consensus, which will make my life much easier when finally implementing what needs to be implemented – and in many cases actually lead to an increase of effectiveness and efficiency, because the time spent on participation is outweighed by the time saved on implementation;
  • get feedback in an early stage that can make the difference between doing something stupid or doing something smart – and so improve our product/outcomes/impacts/benefit to beneficiaries/whatever. In other words: sometimes the street sweeper knows more about how to deal with autumn leaves than the dendrologist.

And now go and add Tales from the Hood to your feed reader – because J.’s writing shows that he doesn’t take his own advice on simplicity too seriously and really thinks about what he does; and that is a treat that is all too rare in the testosterone and adrenaline filled world of humanitarian aid.

[Images: simplicity by Gisela Giardino; Participation 12 pack by dharmabumx. Some rights reserved.

Back to post [1] Okay, so I have to admit that I have thrown that one in purely to be provocative. Can I have a bit of fun sometimes?

{

Continue Reading 2 comments }Aid and aid work

Do you see? Technology aiding supply lines – or not

by Michael Keizer on November 11, 2009

Does your organisation currently have an IC technology project running that aims to improve the supply chain? Odds are that it has, or has had one in the recent past, or is planning one for the near future – that is, if your organisation is anything bigger than a couple of volunteers with a budget of a couple of hundreds of thousands of euros. And you should: continuous improvement of your supply chain is a necessity, and ICT is indispensable to do so.

Or rather, you shouldn’t.

Too often, ICT is implemented as a stand-alone solution for supply line problems. ICT is indispensable to support any but the most trivial of supply lines, but rarely is it a solution by itself for whatever are your supply chain woes.

Does this sound like a truism to you? In fact, it does to me – but I have seen several of these ICT-as-a-panacea projects in aid logistics, so I think it is fair to say that apparently not everybody agrees. Oh, of course management of these projects will pay lip service to the idea that processes, attitudes, knowledge and training, and many other aspects will need to improve too, but in reality you see that everything concentrates on the technological solution: processes are adjusted around the technology, staff are trained in using the technology, and so on. And there we go again, in a straight line towards the next round of ‘technological innovation’.

ICT can help us to build systems that help us get the right information, at the right time, to the right people, at the right price, to make the right decisions and take the right actions. (Sounds familiar? It should.)

But: the operative word here is ‘system’. No, I am not talking about computer systems – when I say system, I refer to (ahem) ’a coordinated whole of human, physical and organisational resources (including procedures and structure), striving for a common goal’. In other words: your logistical department is only just part of the organisation’s logistics system (striving for logistical effectiveness and efficiency), which in its turn is part of the system that is your organisation as a whole (striving to perform whatever is its stated mandate as effectively and efficiently as possible), which in its turn… you get the idea. What is not a system is the shiny new ERP software that your director of resources has just bought after a slick demonstration; it could be part of an effective and efficient system – or it could break it.

I said it before and I will say it again: information and communications technology are indispensable to run anything but the most trivial supply lines; but it is there to serve the goal of those supply lines, and not the other way around. Technology should be part of an integrated system with more or less clearly defined goals. The systems should not be built around the technology, because that will hardly ever lead to real integration; instead technology, procedures, and people should be seen as a indispensable parts of the whole system, giving us eyes to see what is coming – I-see technology instead of IC technology.

(Image: Airborne Caffeine Delivery System by Todd Lappin. Some rights reserved.)

{

Continue Reading 4 comments }Logistics