WHY DO WE WASTE OUR TIME

[Dave Stringer]

on doing "as-is" analysis and modelling?

Surely, if we know the trigger and customer need, we candesign more effectively if we DON'T know 'the way it's always been'.

Are we just making work for no reason?

[Francine Wolfe]

I have often found that doing a current state analysis helps me elicit the customer need. The important thing is to understand WHY it's done the way it's done (other than "the way it's always been". Current state analysis also helps to identify transition requirements (including communications and training).

I'm not advocating in-depth analysis of a legacy system, but a high-level analysis of the business processes provides a great deal of value for eliciting future state requirements. Can't tell you how many times my team skipped the current state analysis (because we thought it wasn't that important or were pressed for time) and found that it hurt us in the end.

[Dave Stringer]

Interesting Francine,
I've always believed that if I can't identify a customer (stakeholder) need then I don't have a starting point and so I don't need a process.


I DO believe in doing a transition analysis prior to migration planning, without that there's no way to identify secure and valid data sources (-_-)

Tell me, do you do process and system together, or do you attack them sequentially?



PS. Nice to know there's someone else out there interested. I thought this was maybe a 'dead' website!!! Now. Where's everyone else (scanning the horizon with great verve!)

[Francine Wolfe]

I always identify the BUSINESS process (including systems involved) first. It's kinda hard to scope out how big the problem is if you don't know what they are currently doing. Another benefit: You can readily identify/measure improvements if you have a documented "as is" process.

Of course, the key is still to minimize the amount of time spent on it...

[Arie Versluis]

Hi Dave and Francine,

I have been inactive for some time (a too long vacation :-)) ).
Nevertheless, I like to respond to this interesting question.

In most situations I do a global as-is analysis. Not only for me to find out how things go, but most and for all for the company-team with whom I cooperate. Such a team has members from all departments. And doing an as-is analysis is in my experience an eye-opener for most team members. Often they realise for the first time what each department does and how the work of their own department can cause problems in other departments.

I prefer the role of the guy who asks the stupid question (That may be the only thing in which I am good), like what happens if you skip a certain process step, why don't people who do the task make the decisions...etc. And questions like what can you do to make work for other departments easier.. and what can other departments do for you.

So actually I prefer to use the as-is analysis mainly as a tool to start a change process and to stimulate team members to come up with ideas for improvement.