Does this apply to government agencies that use policy/laws to dictate business-process'?
Legislation is a funny case because it can be focused on both big picture public policy statements and in the same paragraph drill down to specific and minute detail.
Legislation can also be interpreted different ways depending on the goals of the oganisation.
An obvious example is the powers that police have. Overall police powers are exectuted in a way that constructs certain behaviours and activities based on a combination of legislation and Minister or CEO driven policy. Think of phrases like "Zero tolerance' and 'crack down' - thse are examples of police activity changing as a result of policy change rather than legislation change. If the rulebook hasn't changed, how can their activities really be changing?
Does this make sense?
What it means is that legislation forms only part of the picture. ANd legilation is funny - becasue of that high-level/detail thing. Bu senior management policy and goals are also important.
A quick activity for you: Look up the organisation strategy-on-a-page document on the intranet and have a think about how it informs the work you are investigating.
I hope this helps and am interested in your thoughts on this topic. your reflection on the situation and the choices you make are much more important than the views of people who aren't in the project with you.
Hi:
Level 0, level 1, etc are necessary to handle complexity. I you try to create a "big hunker" flow chart, you inevitably build a "house of cards" that comes crashing down when you edit it, especially when trying larger-scale edits. And models of larger scale systems are going to require larger-scale edits.
Level 0, level 1, etc. are also needed to conceptualize complex systems. Studies show that the human mind can only gasp a max of about 7 function (process) boxes. To limit diagrams to about 7 functions (processes), we create a level 0 with 7 functions, and then decompose to child level diagrams of 7, grand-child diagrams of 7 functions, etc. etc.
Tony
We do have a strategy and there are efforts to move us in that direction. But, it's going to take years to change and document the processes. However, the policy that drives my area of business is our de facto "business process" and it's nothing more than a flow of events and procedures that need to be followed. So, basically, we implement a solution that does nothing more than functionalize the flow from the policy into a UI that assists the user in handling specific scenarios. In other words... We automate the policy w/out concern of how we can "assist" the user.
My goal is to model the "as is" process at the task-level. Then model the "business process" the users have, overlap the two, and create a better tool that is useful to the users. I think this would provide an immediate improvement over what we currently have, but I am getting friction from others stating that you can't start at the task-level with true modeling start from level-0. Again, we can't start at level-0 if we want fast improvements to the processes. Am I off base with this one?
And, if policy dictates a task, no matter the input, the result will be the same. Correct?
brought to you by enabling practitioners & organizations to achieve their goals using: