[
Lists Home |
Date Index |
Thread Index
]
Peter.Hunsberger@stjude.org (Hunsberger, Peter) writes:
>And if the business was big your boss probably handed you a SOP
>manual...
Even in cases where there was an SOP manual, it only covered common
cases. Fortunately, I've never been directly employed in a genuinely
large (>200 people) company, so I mostly read about such things through
Dilbert (ISO 9000 rules!) or heard them from my father at dinner growing
up.
There does seem to be a disconnect between the vendors of standard
operating procedure and the 'prophets of change' who emphasize the need
for flexibility. I can't say I'm fond of either of them, but I suspect
change happens more than SOP is good for and less than the prophets
claim. (Even at my current relatively peaceful publishing job, SOP for
information flows changes substantially about every quarter.)
>Well if the secretaries are the ones with the knowledge that's who you
>talk to get your business rules... Let me be clear, when I say we
>document business rules I don't mean the developers. I mean the
>business analysts (who wouldn't know a DTD from a XSD at the best of
>times) and the end users (who might know how to use Excel and maybe
>Brio). The analysts are also the people who create and review the
>metadata. The developers tweak the metadata to make it consumable by
>our applications, but that's more because the current state of the art
>(the mapping tools) then anything else...
I'm glad that you talk to the secretaries, but I'm still concerned that
you're "getting" rules rather than figuring out how to help them do
their jobs. The current process of data analysis, schema extraction,
and processing design seems okay at getting snapshots of processes, but
imposes enormous overhead on process evolution. Making changes by
calling in top-down consultants isn't exactly an option for the
secretary.
>Absolutely, that's why I say the end user needs Frank the IT guys help
>to create the schema, not the other way around...
Frank the IT guy isn't always available, which is a continuing problem
once these systems are built. Nor are employees necessarily comfortable
explaining their problems to Frank, nor are they necessarily happy to
hand over control of processes they once managed.
XML still seems to me like a great opportunity to let people manage
their own information. Unfortunately, mantras about standardization by
committees of experts have driven committees of experts to build
structures and tools that are only comprehensible by experts.
Developers complain about the tools all the time. Users do their best
to avoid the tools completely, and I can't say I blame them. Very
little of the work being done seems intended to help users communicate.
I need to focus my own energies more squarely on this problem set.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org
|
