Business Process Identification, how low should you go?

[rg2009]

How high level or low level should the first pass at business process identification and requirements gathering be? I had a discussion today with a business member, where they thought I had not identified their business processes properly, but I would categorise what he was describing as an operational procedure. How deep into detail should one go?

[ngalemmo]

Are you designing a data warehouse or an operational system? For a DW I have found that undestanding the data and structures related to the process more critial than the process itself. From a process standpoint its a matter of understanding which processes are dependent or independent of each other. For example, dependent processes would be sales and returns, since, in most cases, the latter affects how the former is caclulated. On the other hand, sales and fulfillment (shipping) are independent, the occur at different times under different circumstances and have different considerations for reporting and analysis.

[rg2009]

Hi ngalemmo,
Thanks for your reply. I'm designing a datawarehouse from scratch so I am just at the very first phaseof requirements gathering. I class business development and account management as business process's, but the business guy is saying that one of his account managers calling Noc to report a problem and have it chased up is a process, but this is not logged anywhere and does not generate data, so to my mind is not a business process. I think it is too low level to be captured at this phase. Am I incorrect in my understanding?

[ngalemmo]

Knowing it occurs is probably enough. As there is no data collection associated with the process, it doesn't have significant bearing on the DW.

There are probably other reasons the business guy is making an issue of it... nothing to do with DW.

[Sponsored content]