Hi again,
My suggestion to you is only "an" approach which we would take which is really rapid to develop and which is really agile. It is to do with your second pararaph on your previous post.
We would only have one single process which would consist of the actions or steps to complete the requirement. Instead of making the process top heavy, we would use an automated process framework as a tool for the actual process, then using our business rules and decisioning tool, which acts as a service to the process we would embed the business logic, or policies, or rules for decisioning.
As the process runs as an automated workflow, it would access the business rules engine as a service and thus provide the business context to the steps in the process, or apply the rules to the data at a specific step of the process to enforce the policies or to perform the decisions as required by the application.
Sorry if it is not clear - feel free to send me a PM to [email protected]
Regards
Nigel
A top-down approach is outside the timeframe of the rewrite. Having said that, can we proceed with an "open" model that will allow for mitigation of misalignment?
When you say Six Sigma, is that the process improvement that is de facto to BPM?
Six Sigma has a framework/overarching process called DMAIC (look it up.) Essentially this framework helps you identify where the most important prblem areas are with a process. You can then go off and address them.
It sounds like you already know that, but you could run a light version of DMAIC across your system to see if you are focusing on the right areas as a quality check.
As for a ground up approach - you'd be best off using some sort of agile approach where you deliver incremental useable features that enable the business to gve you feedback on whether you are going the right way. A tool to help you on that front is a product roadmap.
I hope this is useful and not too abstract for your situation.
If using DMAIC and have identified the problem area(s), can it then be modeled and then proceed w/ a bottom-up appraoch?
You can certainly usea bottom up (ie start with the details) aproach to the as-is analysis. You do need to reconcile what is happenning with the strategic goals, so at some stage you need to know what the top level of the organisation is expecting.
It kind of depends on the context of your project.
I tend to preach the need to stay focused on the higher level goals and processes. Details are important to acknowledge, but getting the big picture, for me, is crucially important and often neglected.
I also tend to measure my contribution in terms of both success and importance to the organsiation. So making what I consider to be significant improvements is part of the deal. This would be a variable based upon where you're at with your career and personal goals.
Anyone of the regulars got a comment on this view?
...You do need to reconcile what is happenning with the strategic goals, so at some stage you need to know what the top level of the organisation is expecting.
Let me explain this point a little.Say your analysis has identified that there is 7% rework rates for a call centre. That is 7% of caler call back within a month with the same issue - becasue ethe first call failed to satisfy them.
You may say GREAT! 7% is a big opportunity. We could shrink this down to 5% and save $1Million in costs.
Yes, sure. But has some thinking already been done in this space? Is the 7% rwork rate considerred accceptable? What's the rate like with competitors? And so on. While it's tre that your million dollar saving would be nice, is there a better opportunity for you just around the corner? For example by automating a particular process or call type?
That's what I am getting at when I say reconcile your discoveries with top level priorities.
brought to you by enabling practitioners & organizations to achieve their goals using: