Catalogue management is one of the trials and tribulations of implementing an eProcurement system. There are many reasons why managed catalogues make absolute sense and yet so many businesses fight it off during process design and system implementation workshops - "it's too hard - we won't be able to maintain it - our suppliers can't give us their catalogs electronically" etc etc.
The following is an excellent article on this topic by Debbie Wilson in Cool Tools for Purchasing.
http://www.purchasingautomation.com/articles/articles173.shtml
I particularly liked the section "Maximizing Catalog-Based System Performance" - as always it's all about people and their behaviour rather than systems and their operation. I smiled broadly when I read this bit.
The final line is a cracker - "if someone tells you that in order to successfully implement eProcurement you must normalize your data, offer requisitioners millions of items to choose from, and insist on certain formats from your catalog suppliers, don’t believe a word of it."
It doesn't have to be hard and it doesn't have to be every item on day one (or ever). It's all about mindset - look for the benefits to your business, pick the targets appropriately, keep it simple and remember the 80/20 rule - probably 80% of your spend is with 20% of your suppliers - focus accordingly and turn the heat up in your negotiations.
However let's not forget about online/web catalogues that a supplier maintains themselves. This can be an excellent way to outsource the responsibility of catalogue management to the supplier - "but how does that help me?" you may ask. With a sophisticated eProcurement solution (like iPOS for SunSystems) you can optionally punch-out to online catalogues and allow users to select items for their shopping basket as normal. The "check out" function on the website actually returns the item list back to your internal/buy side system for processing through the normal budget control and delegated approval rules.
In my experience this is most applicable for the classic low value - high volume suppliers such as office supplies etc where once a contract is in place you want the end-user to be able to select and purchase items with the least amount of fuss and effort. There may be "millions of items" for people to choose from but someone else is doing the hard work of managing them.
Punch-out is also the best way to interact perhaps with government or commercial buying hubs where multiple supplier catalogues may be aggregated. The challenge in leveraging these online marketplaces is the lack of real-time integration to the backend financial management system and the ability to overrun budget and approval controls through poor data integrity.
Punch-out comes with some downsides however:
- You rely on the supplier to maintain the currency of the catalogue and also to accurately apply the service levels of your contract.
- It may not be possible for the supplier to build restricted views of their catalogue for different user profiles in your business - it may be a one-size-fits-all approach.
- They may have more detailed views of your buying habits and trends than you do when it comes to contract negotiation.
- There could even be the ability for "push selling" in their catalogue management that leads people to buy upgrades or additional items or volumes based on the choices they make for their shopping basket.
In reality many organisations may decide to live with a combination approach to their purchasing procedures, internal catalogues for critical business purchases and strategic suppliers, online catalogues for "consumables" and free-form item description for those exceptions that invariably exist (controlled by increased levels of supplier selection, review and approval).
The sensible and reasonable wish of the business is for all options to be managed within a common, process-driven purchasing channel that delivers aggregated spend control and reporting with single source of truth in the financial data.
Tuesday, June 20, 2006
Monday, June 19, 2006
What's the asset number for that process?
Last week I was at the inaugural meeting of the Sydney chapter of BPMG. We had an interesting little get-together with an assortment of players in town. Thank you Bryan for an excellent venue and breakfast. During the general discussion Bridget B from Telstra asked a probing question - why don't processes get treated like assets?
I am two-finger-typing this out on a very uninspiring notebook PC - a modest machine and one of hundreds in the business of course. Flipping it over I spy a little yellow sticker with a barcode and 10 digit number. That's comforting - somebody knows about it and will care for it and come and replace it for me when it dies. But let's face it - it's a commodity that brings little or no value to the business other than what I grind through it each day. Indeed if I drove a stake through its little electronic heart tomorrow I would only have to walk 100 metres in any direction to be able to replace it with a swipe of my credit card. Not much of an asset really.
This afternoon a few of us were workshopping a case study of a fantastic FlowCentric BPMS implementation. Not something I was personally involved with but a great story. An insurance company that automated its stolen vehicle assessment and recovery processes with integration and involvement with complex backend systems and external stakeholders in customs, law enforcement, crash repairers etc etc. The return on investment of this project was only three weeks and the ongoing benefits to the business will I am sure be measured in hundreds of thousands if not millions for years to come.
Does that process have an asset number? I bet not.
What's the big deal - why make it an asset? Because assets get budget allocation and processes need the same level of respect. An effective business process has an intrinsic value to the business but to maintain that value it needs budget. Things change, things that were not possible before are possible in the future, new opportunities arise and legislation interferes in the daily drone with a monotonous regularity. So a process needs to have a budget allocation that ensures it will be improved, rejuvenated, redirected or replaced during its lifetime.
No budget - no love. Give your processes a little yellow asset sticker.
I am two-finger-typing this out on a very uninspiring notebook PC - a modest machine and one of hundreds in the business of course. Flipping it over I spy a little yellow sticker with a barcode and 10 digit number. That's comforting - somebody knows about it and will care for it and come and replace it for me when it dies. But let's face it - it's a commodity that brings little or no value to the business other than what I grind through it each day. Indeed if I drove a stake through its little electronic heart tomorrow I would only have to walk 100 metres in any direction to be able to replace it with a swipe of my credit card. Not much of an asset really.
This afternoon a few of us were workshopping a case study of a fantastic FlowCentric BPMS implementation. Not something I was personally involved with but a great story. An insurance company that automated its stolen vehicle assessment and recovery processes with integration and involvement with complex backend systems and external stakeholders in customs, law enforcement, crash repairers etc etc. The return on investment of this project was only three weeks and the ongoing benefits to the business will I am sure be measured in hundreds of thousands if not millions for years to come.
Does that process have an asset number? I bet not.
What's the big deal - why make it an asset? Because assets get budget allocation and processes need the same level of respect. An effective business process has an intrinsic value to the business but to maintain that value it needs budget. Things change, things that were not possible before are possible in the future, new opportunities arise and legislation interferes in the daily drone with a monotonous regularity. So a process needs to have a budget allocation that ensures it will be improved, rejuvenated, redirected or replaced during its lifetime.
No budget - no love. Give your processes a little yellow asset sticker.
Friday, June 16, 2006
Is darkness your best practice?
Michael Rosemann told a very BPM orientated joke the other week - how many people does it take to change a light bulb?
None - if darkness is best practice.
Hmmm, OK, don't try it onstage at the comedy club but it has a certain drama hook.
Are there monsters in the dark corners of your business that keep you awake at night? Go out and find yourself a process doctor with a bag of light bulbs.
None - if darkness is best practice.
Hmmm, OK, don't try it onstage at the comedy club but it has a certain drama hook.
Are there monsters in the dark corners of your business that keep you awake at night? Go out and find yourself a process doctor with a bag of light bulbs.
Wednesday, June 14, 2006
Business Process Owners touch other peoples stuff
This is a big conundrom in the process management world - when your business is structured in a vertical org-chart or traditional cost centre model and you start down the path of business process improvement just about everyone will tell you that you need Business Process Owners (BPO). They are champions responsible and accountable for the process end-to-end regardless of the edge-to-edge execution across divisional lines.
What that actually means is the BPO needs to be authorised to make changes to processes and tasks within the divisions that intersect with their process. In other words - they touch other people's stuff!
How do you reconcile that in senior management meetings?
I don't think there are any easy answers to this however I have heard of a few approaches to it, some very radical, others less so.
Extreme radical approach - transfer the IT budget out of the CIO role and into the CPO (Chief Process Officer). Budget only gets allocated on a process basis rather than a divisional basis. Of course you probably need to appoint a CPO first. This is for the maturity level 5 organisation perhaps.
Less radical - identify a set of KPIs for the Divisional Managers that are based around the performance of end-to-end process quality and link them to the annual performance bonuses.
Least radical - define service level agreements between the divisions and measure and monitor the process hand off activities and publish the measurements (effectively a leader board/shame list).
BPO's need the authority to make changes in order to improve a process even though the executors of the changes may not be in their reporting line. Indeed, an improvement to a specific process in one area may directly correlate to an increase in cost or responsibility within a division and come with little or no direct benefit. People in general loathe to have multiple bosses as the prioritisation of issues inevitably clash. Companies need to find ways of achieving the process improvements necessary without tearing the business to pieces.
I think in the end the relationship, and maturity, of the senior management team is pivotal in resolving this challenge. Finding common enterprise level goals and methods of measuring and reporting on these is perhaps a good place to start.
What that actually means is the BPO needs to be authorised to make changes to processes and tasks within the divisions that intersect with their process. In other words - they touch other people's stuff!
How do you reconcile that in senior management meetings?
I don't think there are any easy answers to this however I have heard of a few approaches to it, some very radical, others less so.
Extreme radical approach - transfer the IT budget out of the CIO role and into the CPO (Chief Process Officer). Budget only gets allocated on a process basis rather than a divisional basis. Of course you probably need to appoint a CPO first. This is for the maturity level 5 organisation perhaps.
Less radical - identify a set of KPIs for the Divisional Managers that are based around the performance of end-to-end process quality and link them to the annual performance bonuses.
Least radical - define service level agreements between the divisions and measure and monitor the process hand off activities and publish the measurements (effectively a leader board/shame list).
BPO's need the authority to make changes in order to improve a process even though the executors of the changes may not be in their reporting line. Indeed, an improvement to a specific process in one area may directly correlate to an increase in cost or responsibility within a division and come with little or no direct benefit. People in general loathe to have multiple bosses as the prioritisation of issues inevitably clash. Companies need to find ways of achieving the process improvements necessary without tearing the business to pieces.
I think in the end the relationship, and maturity, of the senior management team is pivotal in resolving this challenge. Finding common enterprise level goals and methods of measuring and reporting on these is perhaps a good place to start.
Tuesday, June 06, 2006
Bringing the adminaphobes into the fold
Remember our adminaphobic colleagues with the aversion to administrative tasks outside the areas of their important expertise? Well I have a few thoughts on how we can bring them back into the team.
An empowering strategy in addressing human conflict is the willingness to accept what the other person is saying as true for them in the moment. (Don't get me wrong - you don't have to agree with them, you just need to acknowledge that for them, what they are saying is true).
So take some time to listen to the argument and assess the situation from their point of view. Also, don't fall into the trap of looking for solutions within software systems from the get-go. Pretty much every problem can be solved within the people-process-product continuum (product in this case being software applications) however the people/process corners of the 3P trinity are always the best places to start in my opinion.
Perhaps the problem lies in change management. Does he understand the process? Does he understand the importance of the process? Does he understand his role in the process? Has he been trained in his role? Has he understood and absorbed the training or does he require additional support? Why has he not been able to adopt the expected behaviour as a norm? Is the completion of the process at odds in some way with the goals or KPI's of his job role or team?
It may just be that he is unsure, unconfident, concerned about making embarrassing mistakes, threatened by what the process means to his empire, or just plain missed the communications and education up front in the project.
Now, what about the process? Is it too complex? Can it be simplified? Are there conflicting elements or responsibilities. For very casual executors of the process is there too much collateral information? Or too ambiguous a data/job flow? Are there components of data coming from different sources that may be misunderstood, or overpowering or ambiguous for casual users?
Look into how that process can be improved, simplified and clarified. Other people will appreciate this effort as well.
Sometimes though he may have a valid point. Perhaps there is something about the "product" that is inefficient or ineffective for his role in the process. This then is a great opportunity for the business to improve its processes and enhance its relationship with important members of the workforce. Unfortunately most software applications struggle to adapt flexibly and agilely to very specific user requirements.
This is one of the many sweetspots for a business process management suite (BPMS). The wonderful thing about a BPMS such as FlowCentric is its inherent ability to define and control business processes outside of, and around the edges of, existing applications very cost effectively. It gives business the opportunity to hone areas of process that need to dovetail perfectly into human expectations whilst still leveraging the quite significant investment made in whatever the underlying application is.
A BPMS isn't generally concerned with the transaction end of a process, although this may be part of the outcomes, it is more generally successful in addressing the human element, and that of course is exactly where our adminaphobics sit.
An empowering strategy in addressing human conflict is the willingness to accept what the other person is saying as true for them in the moment. (Don't get me wrong - you don't have to agree with them, you just need to acknowledge that for them, what they are saying is true).
So take some time to listen to the argument and assess the situation from their point of view. Also, don't fall into the trap of looking for solutions within software systems from the get-go. Pretty much every problem can be solved within the people-process-product continuum (product in this case being software applications) however the people/process corners of the 3P trinity are always the best places to start in my opinion.
Perhaps the problem lies in change management. Does he understand the process? Does he understand the importance of the process? Does he understand his role in the process? Has he been trained in his role? Has he understood and absorbed the training or does he require additional support? Why has he not been able to adopt the expected behaviour as a norm? Is the completion of the process at odds in some way with the goals or KPI's of his job role or team?
It may just be that he is unsure, unconfident, concerned about making embarrassing mistakes, threatened by what the process means to his empire, or just plain missed the communications and education up front in the project.
Now, what about the process? Is it too complex? Can it be simplified? Are there conflicting elements or responsibilities. For very casual executors of the process is there too much collateral information? Or too ambiguous a data/job flow? Are there components of data coming from different sources that may be misunderstood, or overpowering or ambiguous for casual users?
Look into how that process can be improved, simplified and clarified. Other people will appreciate this effort as well.
Sometimes though he may have a valid point. Perhaps there is something about the "product" that is inefficient or ineffective for his role in the process. This then is a great opportunity for the business to improve its processes and enhance its relationship with important members of the workforce. Unfortunately most software applications struggle to adapt flexibly and agilely to very specific user requirements.
This is one of the many sweetspots for a business process management suite (BPMS). The wonderful thing about a BPMS such as FlowCentric is its inherent ability to define and control business processes outside of, and around the edges of, existing applications very cost effectively. It gives business the opportunity to hone areas of process that need to dovetail perfectly into human expectations whilst still leveraging the quite significant investment made in whatever the underlying application is.
A BPMS isn't generally concerned with the transaction end of a process, although this may be part of the outcomes, it is more generally successful in addressing the human element, and that of course is exactly where our adminaphobics sit.
Subscribe to:
Posts (Atom)