| Is your IT facilitating your organisation?
|
|
28 Jun 04 |
|
or is IT limiting the evolution of your organisation? Last week, at the
lean service summit, I noticed a common pattern again. Several people were
having problems making their organisational change durable, because
information systems had to be adapted as well. Although some suggested that
because there are no machines to be reconfigured, service processes might
be easier to change than manufacturing processes. In many organisations
this is not true - there are machines in the process, namely computers. And
even though software is in theory infinitely modifiable, practice shows
this is much more difficult.
This is probably caused by two main factors:
- The software being used is complex and/or hard to adapt (this is especially
so for Enterprise Resource Planning systems, where it is probably cheaper
to adapt your company to the software than the other way around).
- The IT department, or whoever is responsible for modifying the software is
not agile, and can not respond quickly to small change requests, necessary
to support ongoing organisational evolution.
A solution towards the first problem, is to have workers rethink their
processes in such a way, that the processes need less software to support
them in the first place. That leaves developers more time to think hard
about the essential software that remains. A solution for the second
problem is to have developers and customers work closely together in short
iterations. This is scary at first – because the developers can no longer
hide behind technical jargon, but have to communicate with the
customers/users in their language.
An example of this is the development of a help desk ticketing system for
an Internet Service Provider that I guided. The chief of the help desk had
noticed that not all problem reports were handled quickly by other
departments. He therefore wanted a system that would enable him to track
the tickets, so he could say how long problem reports took to be solved,
and who was to blame if handling was slow.
A developer started on a requirements and design document. Based on the
design document, the developers estimate was, that it would take two
developers half a year to develop the system (I estimated it would take
even longer).
When the project did get started, we managed to have the chief help desk,
his boss and the two programmers present for the planning meeting. The boss
didn’t want to pay for over half a year of development. If there were
problem reports weren’t handled quickly, she preferred the various
departments communicate with each other, and look for the root cause of the
slowness. This required a much more basic ticketing system. After three
iterations of a week, the basic ticketing system was functional enough to
be put into production.
|