Hacker News new | past | comments | ask | show | jobs | submit login

Your work sounds interesting. Do you capture what really happens in the manual system (trust based work-arounds(1) and all) or do you work from what the procedures say should happen? Just wondering.

(1)E.g. An reference number is needed to set up X on a system. To get a reference number you need to get Y to sign off. Y is notoriously slow, and I have been doing this for years. Z lets me have a reference number on trust knowing that Y will sign off because my paperwork will be in order. Someone new would not get that trust until a few successful cycles. C.F. Lave and Wenger, communities of practice.




We capture what really happens in the manual system, as well as what should happen. Sometimes the latter is pretty vague, or (believe it or not) simply unknown, in which case we learn the very final goal (e.g. "all invoices should be approved in under 24 hours") and work backwards to discover bottlenecks. This can take many weeks, sometimes months, because it requires interviewing subject matter experts.

Implementing the software comes at the very end, ideally when the underlying process itself has been re-engineered. We found that you can't simply take an existing manual process and implement it in software, because if you do then you also capture many of the inefficiencies and bottlenecks.


Excellent answer.

One wonders how you identify the 'subject matter experts', and the extent to which you rely on their answers to questions versus direct observation of what they do.

My experience (anecdotal, informal) is that there can be quite a difference between a verbal description and what actually happens, and the difference has to do with situational knowledge (as in "oh yes, I forgot about Fred. With Fred we do ZZ instead")




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: