In a past life I was responsible for establishing the Application Support function for a wall-to-wall package implementation extended by best-of-breed applications. This division was required to service all users across all systems, in a decentralised organisation i.e. regional accountability for revenue and profitability. There were few centralised services (Marketing, Corporate Finance). The regional offices and distribution centres were autonomous in terms of product, pricing, sales and administration, and themselves very much divided into functional silos (yes, this is a retail company).
In terms of support in the legacy environment it often proved difficult to prioritise issues correctly and typically resulted in a ‘who shouts the loudest’ world of chaos – avalanched further by more tickets from those who did not shout as successfully complaining. Typically, processes involve cross-functional aspects i.e. invoice processing involves products/pricing and debits/credits. What this fact often results in is a support ticket being pushed back and forth between functional teams/departments and, when it eventually falls, it moves from the top of one functional pile to the bottom of another functional pile, thus aging the ticket beyond SLA. Sound familiar?
For the new world order, ITIL processes were implemented for the support teams own practices, however the predicament was how to organise the support teams themselves to be as effective and efficient as possible. We opted for best-practice process centric teams Buy-to-Pay, Order-to-Cash, Hire-to-Retire etc. with a few creations our own, Basket-to-Pay amongst others. Despite the business organisation not being organised to mirror our structure, the approach worked well, and received solid buy-in from the senior business process owners as we were able to respond quickly when a broken ‘product’ process was found to have a ‘finance’ glitch or when a ‘finance’ report was incorrect due to a ‘pricing’ problem. The philosophy was to put soldiers in the same trench, give one the gun and the other the ammo so that they would fight together.
The one significant concern raised was from the support individuals themselves, and that was that they were not sat with their own competency (read function), so we set-up regular structured silo-sessions to ensure functional knowledge and experience was shared.
Yet the positives far outweighed the negatives. This approach enabled the cost/benefit of each process to be calculated as a means to prioritise/categorise support tickets (i.e. revenue generating functions first!), and even when it came to the usually tricky task of negotiating SLAs it was more straightforward to gain consensus across functions by evaluating business processes – as it removed the ego regarding territory, and the process typically flowed through each of their lands.
Finally, I believe that the definition of a Business Process and by extension a Business Process Model, is often misunderstood. It is often considered to be a series of steps (a flowchart maybe) , which it is, to a degree, but it is also a whole lot more. A process transforms an input into an output and is a fairly complex mechanism. As such a BPM should include role definitions (people), steps (tasks and decisions), procedures (instructions and guidelines) and artefacts/deliverables (data), amongst other things. When this perspective is considered more solid Business Processes are built.
Joebert
P.S Just for the record… I’m with you Tony… DFDs rock and UCs don’t! But no one viewpoint will communicate all that must be known, hence the toolkit of supporting conceptual models we have to cover the three views: process, data and behaviour.